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ABSTRACT 


In  recent  years,  many  graphical  approaches  have  been  proposed  to  lift  the 
inconvenience  of  text-based  query  language  among  end-users.  The  new  query 
language  called  DFQL  (DataFlow  Query  Language)  is  a  fully  graphical  interface  to 
the  relational  model  based  on  a  dataflow  paradigm.  It  only  requires  users  to  connect 
some  well-defined  operators  which  have  been  given  an  equivalent  one-to-one 
correspondent  functionality  (or  construct)  in  traditional  query  language  (SQL  in  this 
case).  All  of  the  power  of  current  query  languages  and  sufficient  expressive  power 
and  functionality  are  retained.  But  some  shortcomings  of  DFQL  user  interface  still 
exist. 

This  thesis  is  to  introduce  a  more  ease-to-use  and  ease-to-leam  user  interface, 
so  the  shortcomings  we  found  in  DFQL  user  interface  can  be  lifted  and  the 
productivity  and  power  of  the  new  version  of  DFQL  can  be  increased.  VVe  have 
adopted  object-oriented  programming  approach  in  our  implementation  and  the 
benefits  of  using  object-oriented  programming  in  our  development  are  also 
discussed. 
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I.  INTRODUCTION 


A.  BACKGROUND 

In  the  past  twenty  yeais,  relational  database  management  systems  have  been 
accepted  extensively  for  database  implementation.  To  interact  with  a  database,  users 
of  a  database  management  system  such  as  Ingres  develop  application  programs  by 
embedding  a  data  manipulation  language(e.g.,  ESQL)  in  a  regular  programming 
language(e.g.,  C).  But  those  specialized  text-based  languages  are  somewhat 
unfriendly  to  inexperienced  end-users  (Codd,  1988)  (Codd,  1990,  chpt.23).  In  recent 
years,  many  graphical  approaches  have  been  intioduced  to  lift  the  inconvenience 
among  end-users  (Wu,  1991)  (Wu,  1986)  (Wong,  1982)  (Zloof,  1977)  (Miyao, 
1986). 

A  new  query  language  called  DFQL  (DataFlow  Query  Language)  was  proposed 
in  (Wu,  1991).  DFQL  is  a  fully  graphical  interface  to  the  relational  model  based  on 
a  dataflow  paradigm.  Instead  requiring  users  to  use  traditional  text-based  query 
language,  DFQL  only  require  users  to  connect  some  well-defined  operators  which 
have  been  given  an  equivalent  one-to-one  conespondent  functionality  (or  construct) 
in  traditional  query  language  (SQL  in  this  case).  All  of  the  power  of  cunent  query 
languages  and  sufficient  expressive  power  and  functionality  are  retained.  With  an 
easy  to  use  facilii\  for  extending  the  language,  users  are  allowed  to  define  their  own 
user-defined  operators  by  encapsulating  existing  primitive  operators  and/or 
user-defined  operators  previously  defined  by  users.  The  user-defined  operators 
become  part  of  DFQL  but  can  also  be  deleted  from  DFQL  if  they  are  thought  of  to 
be  no  good  to  exist. 
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As  have  been  presented  previously  in  other  papers  (Angelaccio,  1990  and 
Sckut,  1991),  the  following  goals  are  met  in  DFQL; 

•  Employ  a  fully  graphical  environment  as  aji  user  friendly  interface 
to  the  database. 

•  Sufficient  expressive  power  and  functionality,  including  relational 
completeness. 

•  Ease-of-use  in  learning,  remembering,  writing  and  reading  the 
language's  constructs. 

•  Consistency,  predictability,  and  naturalness  (in  both  syntax  and 
function). 

•  Simplicity  and  conciseness  of  features. 

•  Clarity  of  definition,  lack  of  ambiguity. 

•  Ability  to  modify  existing  queries  to  form  new  queries 
incrementally. 

•  High  probability  that  users  will  write  error-free  queries. 

•  Operator  extensibility'-allow  the  user  to  create  new  operators  in 
terms  of  existing  ones,  analogous  to  defining  a  function  in  a 
programming  language. 

Partial  implementation  of  DFQL  was  done  in  (Clark,  1991).  This  thesis 
improves  some  shortcomings  in  Clark’s  implementation.  For  example,  as  you  can 
see  in  (Clark,  1991 ),  a  new  operator  always  be  created  at  the  upper  left  comer  of  the 
drawing  area.  There  is  no  way  to  create  an  operator  by  directly  typing  at  wherever 
users  like  it  to  be.  After  being  created,  users  are  required  to  drag  the  operator  to  a 
new  location  where  it  is  supposed  to  be.  Several  tedious  steps  of  operation  are 
required  to  simply  delete  an  existing  operator.  Without  creating  an  operator  in  the 
drawing  area  first,  no  on-line  help  message  about  this  operator  can  be  get.  After 
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users  saved  the  help  message  of  a  new  user-defined  operator,  the  content  of  the  help 
message  can  not  be  changed.  So,  should  the  help  message  of  an  user-defined 
operator  need  to  changed,  the  only  way  to  do  is  to  delete  the  operator  permanently 
and  then  redefined  it  and  type  in  the  help  message  carefully  without  any  more 
mistake.  No  more  than  one  DB  INTEFACE  window  (an  interface  window  in  which 
users  construct  queries)  are  allowed  at  the  same  time  is  also  a  severe  limitation  of 
productivity  to  DQFL.  If  more  than  one  DB  INTERFACE  window  is  allowed  to 
exist  at  the  same  time  then  the  reference  to  other  existing  queries  may  be  more 
convenient  during  the  construction  of  a  new  query.  There  are  some  more 
shortcomings  which  we  will  discuss  in  later  chapter  can  be  improved.  All  of  these 
drawbacks  increase  users’  overhead  to  construct  a  query  and  limit  the  productivity 
ofDFQL. 

The  main  concern  of  our  new  development  of  DFQL  as  we  will  discuss  in  the 
later  chapters  is  to  inU'oduce  a  more  ease-to-use  and  ease-to-leam  user  interface,  so 
the  shortcomings  we  found  in  Clark’s  DFQL  interface  need  to  be  lifted  in  order  to 
reduce  the  overhead  of  the  construction  of  queries.  We  believe  that  some  features 
also  need  to  be  incorporated  into  the  new  DFQL  so  that  the  performance  can  be 
improved  and  the  productivity  and  power  of  the  new  version  of  DFQL  can  be 
increased.  For  example,  instead  of  rigidly  creating  a  DFQL  object  at  the  upper  left 
comer  of  the  drawing  area  of  the  queiy  window,  users  should  be  allowed  to  create  a 
new  DFQL  object  simply  by  clicking  the  mouse  anywhere  in  the  drawing  area  and 
entering  the  text  right  on  the  screen.  Multiple  DB  INTERFACE  window  (in  fact, 
as  you  will  see  that  in  our  new  DFQL,  DB  INTERFACE  window  is  replaced  with 
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Query  Window)  and  modification  of  the  on-line  help  messages  of  existing  user- 
defined  operators  are  allowed. 

Since  the  interest  of  this  thesis  is  focused  on  the  user  interface,  the  method  of 
intennediate  code  generation  and  linkage  to  the  existing  backend  database 
management  system  (DBMS)  is  not  covered.  For  those  who  are  interested  in  this 
issue  can  consult  (Clark,  1991). 

B.  OBJECTIVES 

.  We  started  from  the  human  factor  aspects  and  utilized  the  techniques  of  object- 
oriented  programming.  Since,  as  stated  in  last  section,  the  main  concern  of  our  new 
development  of  DFQL  is  to  introduce  a  more  ease-to-use  and  ease-to-leam  user 
interface  the  following  interface  principles  (Wu,  1990)  aie  to  be  met: 


•  Interface  Principle  1;  Be  able  to  provide  more  information  when 
asked. 

•  Interface  Principle  2:  Be  able  to  display  multiple  information  at  the 
same  time. 

•  Interface  Principle  3:  Be  able  to  recover  from  the  unintended  or 
erroneous  operation. 

•  Interface  Principle  4;  Be  able  to  perfoiTn  the  same  operation  in  more 
than  one  way. 

•  Interface  Principle  5:  Be  able  to  prevent  severe  problem  from 
happening. 

•  Interface  Principle  6:  Be  able  to  prevent  modifications  that  are  not 
supposed  to  be  made. 

We'd  also  like  to  discuss  some  important  features  and  benefits  of  object- 
oriented  programming  such  as  reusability,  message  passing,  responsibility  driven. 
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inheritance,  polymorphism,  etc.  we  utilized  in  our  implementation  and  present  some 
experiences  and  lessons  we  learned  during  the  development  of  our  new  DFQL. 

C.  OVERVIEW 

Chapter  II  describes  the  concepts  of  the  previous  DFQL  user  interface  done 
by  Card  J.  Clark,  The  concepts  of  our  new  DFQL  is  basically  the  same  with  those 
introduced  in  this  chapter.  We  also  discuss  the  details  of  how  shortcomings  we  found 
in  the  previous  DFQL  interface  can  be  improved. 

Chapter  III  describes  our  new  DFQL  user  interface  and  introduces  some 
important  features  which  we  have  added  to  the  new  version  of  DFQL.  The  human 
factors  analysis  of  this  new  interface,  and  how  the  interface  principles  we  mentioned 
in  last  section  are  met  is  also  covered  in  this  chapter. 

Chapter  IV  presents  a  brief  intioduction  to  the  programming  language  we  use  - 
-  Prograph  and  describes  why  we  have  adopted  the  object-oriented  approach  and 
evaluates  the  object-oriented  design  of  our  new  DFQL  user  interface 
implementation  and  the  benefits  of  class,  message  passing  and  some  other  features 
of  object-oriented  programming  technique. 

Chapter  V  describes  some  important  lessons  we  have  learned  during  the 
development  of  the  new  DFQL  interface.  A  summaiy  of  this  thesis  is  also  given  in 
this  chapter. 
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II.  PREVIOUS  DFQL  INTERFACE 


A.  CONCEPTS 

As  its  name  says,  DFQL  is  a  DataFIow  Query  Language.  Queries  are  defined 
by  the  user  connecting  the  desired  objects  graphically  in  the  drawing  area  of  a  query 
window.  Upon  completion  of  a  graphically  constructed  query,  the  query  can  be 
translated  to  the  equivalent  text-based  SQL  query  by  the  DFQL  interpreter  and  sent 
off  to  the  backend  database  management  (DBMS)  for  execution.  After  execution, 
the  results  will  then  be  sent  to  the  Query  Results  Window  displaying  on  the 
computer  screen. 

Two  categories  of  objects  aie  defined  in  DFQL  interpreter:  DFQL  operators 
and  text  objects.  Data  are  flowing  from  one  operator  to  another  along  the  query. 
Text  objects  are  used  as  input  data  only,  so  there  is  no  data  flowing  in  to  a  text  object. 
Operator  execution  is  controlled  by  the  presence  of  the  input  data  for  that  operator. 
When  all  the  data  required  become  available  the  operator  may  execute  or  fire. 

1.  DFQL  Operators 

There  are  two  categories  of  operators  defined  in  DFQL  interpreter: 
primitive  operators  and  user-defined  operators.  An  user-defined  operator  is  one 
that  has  been  constructed  by  the  user  from  primitive  operators  and  possibly  other 
previous  created  user-defined  operators.  So  we  can  say  that  an  user-defined  operator 
is  a  compact  query  with  some  essential  input  data  unspecified. 

All  operators  in  both  categories  except  operators  DISPLAY  and 
SDISPLAY  (we  will  mention  them  later)  have  the  same  appearance.  A  sample 
operator  named  select  is  shown  in  Figure  II.  1  below.  Each  operator  is  made  up  of 
three  components:  the  body  with  the  name  of  the  operator,  the  input  nodes  and  the 
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input  nodes 


body  with  select 
as  its  name 


output  node 


Figure  11.1  Operator  Construction 


output  node.  They  can  have  multiple  input  nodes  but  there  is  only  one  output  node 
for  each  operator. 

The  body  of  the  operator  is  the  rounded-rectangle  with  the  input  nodes  and 
output  node  attached  to  it.  The  input  nodes  and  output  node  are  represented  by  small 
circles.  The  input  nodes  are  where  the  data  from  other  operator  or  text  object  flowing 
into  or  fed  into  the  operator.The  output  node  is  where  the  result  of  the  execution  of 
this  operator  flowing  out  of  the  operator.  The  intermediate  suit  of  a  operator  may 
then  be  passed  to  other  operator(s)  by  connecting  the  operator’s  output  node  to  other 
operator's  input  node(s).  An  output  node  can  be  connected  to  multiple  input  nodes 
whereas  an  input  node  can  only  be  connected  to  exactly  one  output  node.  The  output 
from  each  operator  is  always  a  relation. 

The  appearance  of  operators  DISPLAY  and  SDISPLAY  is  shown  in  Figure 
II.2.  We  are  intended  to  make  them  different  from  other  operators  because  as  we  will 
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r  Q-0  I 
iDISPLflVl 


Figure  II.2  Construction  of  DISPLAY  and  SDISPLAY 

see  later  that  these  two  operators  aie  not  provided  to  execute  query  functions  but  to 
allow  user  to  print  the  contents  of  relations  on  the  computer  screen.  They  create  no 
results. 

a.  Primitive  DFQL  operators 

There  are  fifteen  DFQL  primitive  operators  provided  in  DFQL 
interpreter.  Among  them,  there  are  six  basic  operators.  These  six  primitive  DFQL 
operators  and  a  corresponding  uanslation  into  SQL  aie  shown  in  Figure  II.3.  The 
other  primitive  operators  are  shown  in  Figure  II .4. 

b.  User-Defined  Operators 

With  user-defined  operators,  users  can  construct  their  own  operators  for 
situations  that  are  unique  to  their  query  needs  and  give  those  new  defined  operators 
names  that  reflect  the  functions  they  perform.  For  example,  instead  of  creating  a 
query  as  shown  in  Figure  II.5,  we  can  define  an  operator  sel-project  and  construct 
the  query  as  shown  in  Figure  II.6,  where  operator  sel-project  is  defined  by 


-  Q.  Q-0— 
ISDISPLflVl 
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DFQL  Operator  SQL 


rtUtion  condition 


SELECT  DISTINCT  ♦ 
FROM  relation 
WHERE  condition 


reUtion  attribute  list 


fproj^tl 


SELECT  DISTINCT  * 
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Figure  11.3  DFQL  Basic  Operators 
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Figure  II.4  Other  DFQL  Operator 
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combining  primitive  DFQL  operators  select  and  project.  We  will  discuss  how  to 
define  an  user-defined  operator. 


student  gpa  >3.5 


Figure  11.5  A  Sample  Query 


9pa  >3.5 


Figure  11.6  An  User-Defined  Operator 
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The  most  significant  advantage  gained  from  the  utilization  of  user- 
defined  operators  is  that  abstraction  of  complicated  queries  into  a  single  user- 
defined  operator  is  allowed.  This  make  it  easier  to  understand  and  use  operators 
correctly.  It  also  conserves  space  of  the  drawing  area  in  the  query  window. 

2.  Text  Objects 

A  special  notation  is  used  to  provide  textual  input  to  the  DFQL  operators. 
Text  entered  by  the  user  shows  up  in  the  query  window  as  an  object  with  the  text 
attached  to  an  output  node  as  shown  in  Figure  II.7.  The  text  object  can  be  interpreted 


A  Text  Object 
- O - 

Figure  11.7  Text  Object 

in  two  different  ways.  If  the  text  is  the  name  of  a  relation,  the  output  at  the  root  can 
be  thought  of  as  an  instance  of  that  specific  relation.  If  the  text  represents  a 
condition,  a  list  attributes,  or  some  other  textual  input  to  another  DFQL  operator, 
then  the  text  is  passed  on  to  that  operator  as  a  textual  argument. 

3.  DFQL  Query  Construction 

All  DFQL  queries  exist  as  a  dataflow  program  in  which  text  objects  and 
operators  are  connected  by  dataflow  paths.  The  data  flow  paths  are  represented  as 
the  lines  in  the  DFQL  query  that  connect  the  input  and  output  nodes  of  the  DFQL 
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objects.  Execution  of  the  query  can  be  visualized  as  flowing  from  the  top  of  the 
diagram  to  the  bottom.  When  the  input  arguments  to  an  operator  are  available,  that 
operator  may  execute,  or  fire,  producing  its  output  which  will  then  flow  on  to  the 
other  connected  operators.  Since  text  objects  have  no  inputs,  they  may  fire  at  any 
time.  Execution  of  the  query  continues  until  all  input  has  been  exhausted.  The 
general  idea  behind  DFQL  query  construction  have  been  presented  in  (Clark,  1991). 
Instead  of  getting  into  all  the  details,  we  give  an  sample  query  as  shown  in  Figure 
11.8  below. 


pay  >=  50000 


Figure  II.8  A  Sample  Query 
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This  query  uses  the  diff  operator  to  return  the  IlD  of  instructors  in  CS 
department  whose  pay  is  lower  than  50,000  dollars.  In  this  query  the  user-defined 
operator  sel-project  from  Figure  II.6  is  used. 

B.  SHORTCOMINGS  OF  THE  PREVIOUS  DFQL  INTERFACE 


The  previous  DFQL  interface  as  shown  in  Figure  11.9  is  made  up  of  a  DB 
INTERFACE  window  and  a  menu  with  eight  menu  items.  The  DB  INTERFACE 


Figure  11.9  DB  INTERFACE 
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window  is  the  main  interface  from  which  users  can  construct  their  queries.  The 
description  of  these  components  can  be  find  in  (Clark,  1991).  We  just  present  some 
shortcomings  we  found  in  it  and  discuss  what  we  can  do  about  them. 

1.  Tedious  Query  Construction 

The  most  significant  drawback  in  the  Clark’s  DFQL  interpreter  is  the  way 
to  create  an  object  in  the  DB  INTERFACE  window.  Every  time  an  object's  button 
(either  DFQL  operator  or  text  object)  on  the  left  portion  of  the  DB  INTERFACE 
window  is  clicked  or  an  item  (operator’s  name)  from  menu  item  Primitives  of  the 
main  menu  (Figure  II.  10)  is  selected,  DFQL  always  creates  it  on  the  very  upper  left 


File  Edit 

Primitiues 

UserOps  Options...  Info  Special 

eqjoin 

groupflLLsatisfy 

groupaug 

groupmau 

groupmin 

groupNsatisfy 

intersect 

DISPLAY 

SDISPLflV 

Figure  11.10  Primitives  Menu 

comer  of  the  drawing  area  in  the  DB  INTERFACE  window  (Figure  II.ll,  an 
operator  named  union  is  created  in  the  DB  INTERFACE).  In  order  to  put  it  on  the 
right  place  where  the  object  is  supposed  to  be,  the  user  need  to  click  the  object  and 


Figure  II. 11  Creation  of  an  Operator 


drag  it.  But  if  the  checkable  menu  item  Select  in  the  Edit  menu  (Figure  11.12)  is 
checked  then  all  of  sudden,  when  the  user  click  the  object  in  order  to  drag  it,  she(he) 
will  find  that  instead  of  dragging  it,  the  object's  color  is  converted.i.e.,  the  object  is 
selected  to  be  deleted  or  deselected.  So  the  user  need  to  uncheck,  or  turn  off  Select 
and  then  drag  the  object.  Figure  11.13  shows  a  selected  operator 

Not  being  able  to  create  a  text  object  by  directly  typing  on  the  drawing  area 
is  another  drawback.  So  we  believe  that  allowing  the  user  to  locate  the  exact  location 


w  File  nmi  Primitiues  UserOps  Options...  Info  Special; 


Figure  11.12  Edit  Menu 


Figure  11.13  A  Selected  Operator 

for  the  next  object  by  simply  clicking  anywhere  in  the  drawing  area  and  then  typing 
in  the  text  or  an  existing  operator's  name  directly  will  ease  the  user's  duty. 

To  create  an  user-defined  operator  in  the  drawing  area,  an  awkward  process 
requires  the  user  to  select  the  menu  item  Select  from  menu  UserOps  (Figure  11.14) 
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and  selects  the  specific  user-defined  operator  from  a  dialog  box  (Figure 
11. 15). Allowing  the  user-defined  operators  to  be  created  the  same  way  as  primitive 
operators  are  would  be  a  better  solution.  We  will  see  how  this  procedure  can  be  eased 
in  our  new  implementation. 


w  File  Edit  Primitiues 


UserOps 
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Figure  11.14  UserOps  N'enu 


USER  DEFINED  CPERATORS 


selpfi.  j 
usel 

user-groupALLsatisfy 

usrgas 

zeroin 


O 


Select 


Cancel 


Figure  11.15  Dialog  Box  for  User-Defined  Operator  Selection 


2.  Tedious  Delete  Operation 

To  delete  an  object  from  the  drawing  area  of  the  DB  INTERFACE 
window,  the  user  also  need  to  check,  or  turn  on  Select  first  and  tlion  select  the  menu 
item  Delete  from  menu  Edit.  To  make  the  delete  operation  easier,  we  will  point  out 
another  way  to  delete  objects  without  to  check  Select  first.  That  is  to  say  that  Select 
is  no  longer  needed  in  our  new  implementation  of  DFQL  interpreter  and  can  be 
remove. 

3.  No  Concurrent  Query  Constructions 

No  more  than  one  DB  INTEFACE  window  are  allowed  at  the  same  time  is 
also  a  severe  limitation  of  productivity  to  DQFL.  If  more  than  one  DB 
INTERFACE  window  is  allowed  to  exist  at  the  same  time  then  the  reference  to 
other  existing  queries  may  be  more  convenient  during  the  construction  of  a  new 
query  and  users  are  also  able  to  construct  multiple  queries  in  different  windows  at 
the  same  time. 

4.  Rigid  User  Operator  Definition 

To  create  a  new  user-defined  operator,  previous  DFQL  disables  the  object 
creation  and  deletion  abilities.  So  the  desired  internal  structure  for  the  new  user- 
defined  operator  must  be  exist  in  the  drawing  area  before  getting  into  the  operator 
definition  mode.  This  means  that  if  the  user  want  to  define  a  new  operator  during  the 
process  of  query  construction,  he  (she)  needs  to  delete  some  operators  unneeded  in 
the  structure  of  the  new  operator.  While  in  the  operator  definition  mode,  if  the  user 
find  that  some  operators  need  to  be  added  to  or  deleted  from  the  internal  structure  of 
the  new  operator  being  constructed,  he(she)  need  to  give  up  all  the  efforts  done 
before  and  return  to  the  query'  construction  mode  then  add  or  delete  some  operators. 
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We  believe  that  all  the  object  creation  and  deletion  abilities  should  be  retained  in 
operator  creation  mode  so  the  user  does  not  need  to  go  back  and  forth  between  query 
construction  and  operator  definition  modes. 

5.  Reference  Information  Exit  Too  Short 

After  viewing  the  internal  structure  of  an  user-defined  operator,  the  window 
in  which  the  internal  structure  of  the  user-defined  operator  is  displayed  need  to  be 
closed  before  the  user  can  proceed  to  do  other  stuff.  The  window  and  its  contents  are 
not  allow  to  stay  available.  This  means  that  every  time  when  the  user  need  to  view 
the  internal  structure  of  an  user-defined  operator,  the  viewing  procedure  need  to  be 
repeated.  This  is  also  a  drawback  needed  to  lifted. 

6.  Restricted  Way  of  Getting  Help 

The  previous  DFQL  provides  help  information  describing  each  operator  by 
requiring  the  user  to  double-click  on  an  operator  existing  in  the  drawing  area.  This 
is  the  only  way  to  get  the  information  of  an  operator.  So  it  is  impossible  for  an  user 
to  get  the  information  of  any  operator  before  it  is  created  in  the  drawing  area.  But  it 
is  always  the  case  that  users  need  to  consult  the  help  messages  of  operators  from 
time  to  time,  especially  for  user-defined  operators.  This  need  is  more  obvious  when 
the  number  of  user-defined  operators  gets  larger.  So  when  users  are  not  really  sure 
what  the  functionality  of  an  operator  they  may  want  to  use  is,  we  can  not  expect 
them  to  tolerate  the  inconvenience  of  creating  an  operator,  double  clicking  it  to  get 
the  help  message,  finding  out  that  it  is  not  what  exactly  they  want  and  then  go 
through  the  same  procedures  again  to  try  other  operators.We  will  added  some  more 
features  of  on-line  help  to  our  new  DFQL  interface. 
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III.  NEW  DFQL  INTERFACE 


Like  the  previous  DFQL,  new  DFQL  is  also  implemented  on  an  Apple 
Macintosh.  Basic  operations  of  this  implementation  depend  heavily  on  use  of  the 
mouse  and  pull-down  menus.  In  this  section  we  present  an  detailed  discussion  on 
how  the  user  interacts  with  the  DFQL  inteipreter  to  consuuct  and  execute  queries. 

A.  STARTING  THE  PROGRAM 

Upon  start-up,  the  user  is  presented  with  the  screen  shown  below  as  Figure  III.l . 
We  do  not  use  DB  INTERFACE  as  the  title  of  the  main  window,  instead,  we  use 
Query  Window  followed  by  an  number  indicating  the  sequential  order.  That  is 
because  we  allow  multiple  Query  Windows  to  exist  at  the  same  time  in  our  new 
DFQL.  So  what  we  see  upon  stail-up  is  a  main  w  indow  entitled  Query  Window  1 
along  with  a  pull-down  menu. 

B.  QUERY  WINDOW  AND  ITS  ITEMS 

A  Query  Window  as  shown  in  Figure  III.l  can  be  moved,  resized,  closed  and 
roomed  by  utilizing  the  basic  functions  of  Apple  Macintosh.  We  assume  that  readers 
are  all  aware  of  those  functions. 

1.  Buttons 

The  Run  button  executes  the  query  which  is  currently  constructed  in  the 
drawing  area.  Run  will  first  check  that  the  query  is  conectly  constructed.  Then  the 
query  will  be  sent  off  to  the  backend  DBMS  for  processing.  Query  results  returned 
from  the  database  will  be  displayed  in  a  separate  Query  Result  Window  (Figure 
III.2).  We  will  mention  Query  Result  Window  later. 
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Figure  III.l  Query  Window 


22 


k 


•hroll  tpstscore  >=  95 


Figure  111.2  A  Query  and  its  Query  Results  Window 


The  New  button  creates  a  new  Query  Window  N,  where  N  is  the  number 
indicating  that  this  is  the  Nth  Query  Window  opened  since  the  start-up  of  the  DFQL 
interpreter.  When  a  new  Query  Window  is  opened,  a  query  filename  Untitled  #N, 
where  N  is  the  same  number  as  that  in  the  title  of  the  Query  Window.  All  Query 
Windows  retains  all  capabilities  as  the  first  one  does.  By  creating  new  Query 
Windows,  the  user  is  allow  to  consuaict  queries  in  different  Query  Windows 
concurrently.  This  feature  make  the  DFQL  more  productive. 

The  Open  button  allows  the  user  to  retrieve  a  previously  saved  query  file 
from  disk.  When  Open  is  clicked,  a  dialog  box  is  presented  from  which  the  user  can 
select  the  stored  query  file  for  retrieval.  Before  a  selected  query  file  can  be  retrieved 
onto  a  Query  Window,  DFQL  will  check  if  it  has  been  opened  in  any  Query  Window 
or  if  there  is  any  query  with  the  same  file  name  exists  in  any  Query  Window.  If  this 
situation  is  true,  then  DFQL  will  prompt  a  message  telling  the  user  that  in  which 
Queiy  Window  the  query  file  selected  has  been  opened.  This  feature  agrees  with 
Interface  Principle  5:  Be  able  to  prevent  severe  problem  from  happening.  If  the 
selected  query  file  has  not  been  opened,  it  is  inuriediately  retrieved  onto  the  Query 
Window  and  the  query  (the  content  of  the  newly  opened  file)  appears  in  the  drawing 
area.  The  previous  filename  assigned  to  the  Query  Window  will  be  replaced  by  the 
new  one. 

The  Save  button  stores  the  cunent  query  onto  disk  with  the  name  that  is 
currently  assigned  to  the  query.  The  Save  as  button  allows  the  user  to  store  the 
current  query  with  a  new  name.  When  Save  as  is  clicked,  a  file  naming  dialog  box 
displayed.  The  user  can  enter  the  new  file  name  for  the  current  quer>’  to  be  saved.  If 
the  entered  file  name  matches  an  existing  file  in  any  Quer  y  Window,  the  user  will  be 
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prompt  that  a  file  with  this  name  is  cuirently  opened  in  a  specific  Query  Window  and 
the  save  operation  is  abandoned  and  the  file  naming  dialog  box  appears  again  asking 
the  user  to  enter  a  new  filename.  On  the  other  hand,  if  the  entered  filename  matches 
an  existing  file  in  the  disk,  the  user  will  be  asked  whether  or  not  he(she)  really  want 
to  replace  the  previous  stored  file.  If  not.  the  user  can  either  abandon  the  saving 
attempt  or  enter  a  new  name.  When  an  appropriate  name  has  been  given  the  query 
will  be  saved  to  disk. 

The  Reset  button  clears  the  cuirent  query  from  the  drawing  area  and  from 
the  computer's  memory.  When  the  user  has  no  desire  to  save  the  current  query.  Reset 
can  be  used  to  set  up  a  new  quejy.  This  is  also  a  shortcut  to  delete  all  objects  in  the 
drawing  area  and  give  the  user  a  blank  drawing  area  to  stait  constructing  a  new 
query.  After  Reset.  Untitled  #N  is  assigned  as  the  file  name  to  the  Query  Window 
N  again.  This  feature  which  prevent  the  user  from  “destroying”  an  existing  query  file 
by  simply  clicking  the  mouse  on  the  Reset  button  is  also  based  on  Interface 
Principle  5:  Be  able  to  prevent  some  severe  problem  from  happening. 

2.  Drawing  area 

The  drav^ing  area  is  the  portion  of  the  Quei7  Window  that  is  bounded  by 
the  horizontal  and  vertical  scroll  bais.  This  aiea  starts  out  blank  and  is  used  to 
graphically  construct  the  DFQL  query.  As  the  query  becomes  larger  so  that  portions 
of  drawing  ar  ea  ar  e  hidden  from  the  user's  view,  the  scroll  bar  s  may  be  used  to  bring 
the  hidden  ponion.s  into  view.  There  are  two  ways  to  create  an  object:  First,  the  user 
clicks  the  mouse  anywhere  he(she)  wants  the  object  to  appear  in  the  drawing  area. 
An  “input  box”,  the  gray  rectangle,  with  a  flashing  cursor  at  the  center  appears  on 
where  the  mouse  is  clicked  waiting  for  the  user  to  enter  any  text  from  the  keyboard. 
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After  the  input  box  shown  up,  the  user  can  select  either  an  operator  from  the  pop-up 
menu  Primitive  or  an  user-defined  operator  from  the  other  pop-up  menu  UsrOpr 
by  clicking  on  the  up-side-down  triangle.  The  input  box  will  be  replaced  with  the 
selected  operator  or  user-defined  operator.  The  second  way  is  also  clicking  in  the 
drawing  area  to  create  an  input  box  first  and  then  keep  typing  in  text.  Should  there 
be  any  typing  mistake,  the  delete  key  on  the  keyboard  can  be  used  to  delete  the 
mistyping  characters.  As  the  Return  key  is  pressed,  the  text  input  ended  and  the 
DFQL  interpreter  checks  whether  or  not  the  entered  text  is  in  the  name  list  of  the 
primitive  operators  or  user-defined  operators.  If  it  is,  then  the  operator  whose  name 
is  entered  will  appears  in  the  drawing  area  and  centered  at  where  the  mouse  is 
clicked.  If  the  entered  text  is  not  in  the  naine  list  of  the  primitive  operators  or  user- 
defined  operators,  a  text  object  with  the  text  entered  will  appear  and  is  also  centered 
at  where  the  mouse  is  clicked.  There  is  an  example  shown  in  Figure  II1.3.  The 
feature  allowing  operators  to  be  created  in  more  than  one  way  supports  the  interface 
Principle  4:  Be  able  to  perform  the  same  operation  in  more  than  one  ways. 

The  DFQL  interpreter  is  case  sensitive.  If  the  entered  text  is  Select  instead 
of  select  (the  name  of  a  primitive  operator)  and  we  do  not  have  an  user-defined 
operator  named  Select,  then  it  is  created  as  a  text  object,  not  an  operator.  If  no 
characters  are  entered,  after  pressing  the  Return  key,  the  “input  box”  will 
disappears. 

In  order  to  construct  a  DFQL  query,  the  quei7  objects  must  connected  with 
the  desired  data  flows.  Data  flows  are  the  lines  connecting  output  node  of  any  given 
object  to  the  input  node  of  another  object  (or  objects).  To  draw  these  lines,  the  user 
must  click  the  mouse  on  either  an  output  or  input  node.  Once  the  mouse  button  has 
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click,  to  create  an  input  box 
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Figure  IIL3  Creating  an  Operator  by  Typing 

been  released,  a  rubber-band  line  will  be  drawn  from  that  node  to  the  current 
position  of  the  mouse.  Clicking  on  the  input  node  or  output  node  of  another  object 
will  connect  the  dataflow  line  from  the  originating  node  to  the  newly  indicated  node 
if  the  connection  makes  sense.  The  following  attempted  connections  do  not  make 
sense: 


From  input  to  input 
From  output  to  output 
Between  nodes  of  the  same  operator 
Making  a  cycle 
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Should  any  of  these  nonsense  connections  be  detected,  an  error  message  is 
presented  stating  that  the  attempted  connection  is  not  allowed.  While  the  rubber- 
band  line  is  “on”,  clicking  the  mouse  in  an  blank  portion  of  the  drawing  area  will 
turn  off  the  rubber-band  line  if  the  user  has  decided  not  to  make  a  connection  after 
all.  Since  an  input  node  may  have  only  one  input  flow,  if  the  user  connects  a  dataflow 
line  to  an  input  node  that  aheady  had  one,  the  previous  dataflow  line  is  deleted 
automatically. 

In  order  to  move  an  object  within  the  drawing  area,  the  user  clicks  the 
mouse  on  the  object  and  drags  it  to  the  desired  position  while  holding  down  the 
mouse  button.  If  the  user  clicks  the  object  and  release  the  mouse  button  immediately, 
the  object  will  be  selected,  i.e.,  its  color  will  be  converted.  Selecting  a  DFQL  object 
existing  in  the  drawm;;  area  has  two  effects.  First,  it  allows  the  selected  object  to 
deleted.  Secoad'_),  selecting  a  DQFL  operator  allows  the  user  to  retrieve 
intermediate  results  from  the  queiy  When  an  operator  is  selected  and  the  Run 
button  is  clicked  in  the  Query  Window,  The  quei7  will  be  executed  up  to  and 
including  the  selected  operator.  The  result  of  this  pai  tial  query  will  then  be  displayed 
in  the  Query  Result  Window.  To  delete  a  selected  object,  the  user  can  select  the  menu 
item  Delete  from  the  menu  Edit.  The  equivalent  operation  to  delete  a  selected  object 
is  simply  pressing  the  Command  and  D  keys  on  the  keyboard  simultaneously.  The 
user  is  also  allowed  to  select  seve-'a!  objects  and  then  delete  them  all  at  one  time. 
However,  an  object  selected  can  still  be  moved  around  in  the  drawing  area.  Simply 
clicking  the  mouse  on  a  selected  object  will  deselects  it. 

Double-clicking  either  on  an  primitive  operator  or  on  an  user-defined 
operator  will  bring  up  a  help  window  describing  that  operator.  The  Help  Window  is 
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shown  in  Figure  III.4.  The  left  portion  of  the  Help  Window  is  a  scrolling  list  of  the 
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Figure  1II.4  Help  Window 


names  of  all  operators.  The  highlighted  name  is  the  one  we  double-clicked  on.  The 
message  shown  in  the  right  portion  of  Help  Window  is  the  description  of  the 
highlighted  operator. 

Double-clicking  on  a  text  object  opens  up  an  editor  for  that  object's  text 
string.  All  of  the  Macintosh 's  normal  text  editing  functions  such  as  cutting,  copying, 
and  pasting  text  from  the  Macintosh  clipboard  are  supported  in  this  editor.  When  the 
OK  button  is  clicked,  the  previous  text  for  the  object  is  replaced  with  the  new  string. 

If  the  mouse  is  double-clicked  on  an  output  node,  the  columns  of  the 
relation  flowing  out  of  that  node  are  displayed. In  this  way,  the  user  can  determine 
what  attributes  may  be  used  by  operators  subsequent  to  that  point  in  the  query  graph. 
This  assistance  is  very  important  in  the  construction  of  large  queries  in  which  the 
attributes  become  hard  to  keep  uack  of.  Also,  when  user-defined  operators  are  used. 
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it  is  important  to  be  able  to  easily  detemiine  what  the  names  of  the  attributes  are  that 
the  operator  produces.  There  is  an  example  shown  in  Figure  III.5. 


COLUMN  NAMES: 

SID,  SNAME,  ADDR,  PHONE,  GPA 


Figure  III.5  Columns  of  a  Relation  at  the  Output  of  select 


3.  Pop-up  menus 

There  are  two  pop-up  menus  in  the  Query  Window:  Primitives  and 
UsrOpr.  Primitives  contains  the  names  of  all  primitive  operators  while  UsrOpr 
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contains  the  names  of  all  the  user-defined  operators.  When  a  new  user-defined 
operator  is  created,  its  name  will  be  attached  to  the  end  of  UsrOpr. 

These  two  pop-up  menus  provide  another  way  to  create  an  operator.  After 
the  user  clicks  the  mouse  on  the  drawing  area  to  create  an  input  box,  instead  of 
entering  text  from  the  keyboard,  the  user  can  also  click  on  the  reversed  triangle  of 
either  pop-menus  depending  on  what  kind  of  operator  he(she)  want  to  create  and 
then  selects  the  specific  operator  from  the  pop-up  menu  list.  The  input  box  will  be 
replaced  with  the  selected  operator. 

C.  OPERATOR  DEFINITION  WINDOW 

When  the  menu  item  New  in  menu  UserOps  is  selected,  the  Operator 
Definition  Window  as  shown  in  Figure  III.6  is  displayed  on  the  computer  screen. 
The  Operator  Definition  Window  is  very  similar  to  Query  Window.  The  difference 
between  these  two  windows  are  that  they  have  different  set  of  buttons  and  there  is 
an  “input  bar”  in  the  drawing  area  of  the  Operator  Definition  Window. 

The  drawing  area  plays  exactly  the  same  role  as  that  in  the  Query  Window  does. 
The  input  bar  is  used  to  define  where  the  input  data  to  the  user-defined  operator  w  ill 
be  sent  internally.  Clicking  the  mouse  on  the  input  bai'  will  create  additional  input 
nodes  for  the  user-defined  operator.  If  too  many  input  nodes  aie  created  by  mistake, 
they  can  be  remo\ed  by  clicking  the  mouse  on  the  Delete  Input  button.  Each  click 
deletes  one  input  nodes  from  the  input  bar.  Once  the  desired  number  of  input  nodes 
are  created,  they  must  be  connected  to  the  desired  operators  in  the  drawing  area.  All 
input  nodes  of  the  operators  inside  the  user-defined  operator  must  be  connected. 
Also,  there  may  be  only  one  unconnected  output  node  in  the  user-defined  operator. 
This  single  node  becomes  the  output  node  for  the  entire  user-defined  operator. 
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Figure  III.7  Operator  Definition  Window 

When  the  Store  button  is  clicked,  DFQL  interpreter  first  check  the  internal 
structure  of  the  user-defined  operator  to  ensure  that  all  necessary  connections  have 
been  made  and  query  criteria  have  also  been  met.  Then  the  user  will  be  asked  a  name 
for  the  new  defined  operator  and  a  description  that  will  be  used  as  help  message  for 
the  operator.  This  feature  agrees  with  Interface  Principle  1:  Be  able  to  provide 
more  information  when  asked.  The  operator's  name  is  checked  for  uniqueness 
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among  all  existing  operators.  If  the  uniqueness  is  ensured,  the  name  of  the  new  user- 
defined  operator  will  be  added  to  the  end  of  the  scrolling  lis  of  Help  Window  and 
the  UsrOpr  pop-up  menu  list  so  the  user  can  use  it  immediately.  New  DFQL  allows 
users  to  define  user-defined  operators  successively  as  many  as  their  want. 

The  Clear  All  button  clears  the  drawing  area  and  allows  the  user  to  reconstruct 
the  user-defined  operator.  The  Cancel  button  cancels  all  the  operations  the  user  has 
done  since  the  start  of  the  definition  of  a  new  operator. 

D.  MENU  ITEMS 

The  items  listed  in  the  main  menu  (Figure  Ill.l)  usually  remain  the  same 
throughout  the  whole  session  of  the  application  no  matter  what  w  indow  is  currently 
displayed.  Any  items  that  are  not  applicable  at  a  given  time  aie  made  unselectable 
and  are  displayed  at  reduced  intensity,  commonly  known  as  being  “grayed  out”.  We 
also  provide  equivalent  key-combinations  for  some  menu  items  to  speed  up  the 
user's  operations.  This  feature  suppoits  Interface  Principle  4:  Be  able  to  perform 
the  same  operation  in  more  than  one  ways.  The  menu  items  are  discussed  below. 

1.  Apple 

Apple  is  a  standard  Macintosh  menu  that  has  no  relation  to  DFQL.  It 
provides  access  to  Macintosh  utilities  called  “Desk  Accessaiy”  and  should  be 
accessible  at  all  times  (Apple,  1985,  p.  1-54).  The  only  DFQL  specific  item  in  this 
menu  is  the  “About..”.  When  this  item  is  selected,  a  brief  information  about  DFQL 
interface  is  displayed. 
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2.  File 


As  shown  in  Figure  III.7,  the  New  item  executes  exactly  the  some  function 
as  the  New  button  in  the  Query  Window.  It  is  very  possible  that  the  user  may  close 
the  only  Query  Window  unintendedly.  Without  this  New  item,  the  user  will  not  be 
able  to  open  any  new  Query  Windows  and  need  to  quit  DFQL  unwillingly.  This  New 
item  is  provided  basing  on  Interface  Principle  4:  Be  able  to  perform  the  same 
operation  in  more  than  one  ways  and  Interface  Principle  3:  Be  able  to  recover 
from  the  unintended  or  erroneous  operation. 


Edit  UserOps  Option...  Info  Special  Lilindoiu 
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Print... 
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Quit 

Figure  III.7  File  Menu 

The  Page  Setup...  item  iz  also  a  standaid  Macintosh  File  menu  item  which 
allows  the  user  to  change  printer  paiameters  such  as  the  size  of  paper,  print  quality 
and  orientation.  The  Print...  item  is  provided  to  print  out  the  infoimation  of  the  front 
window  of  the  DFQL. 

The  Quit  item  closes  all  opened  windows  and  terminates  the  DFQL 
interpreter  execution.  Before  closing  each  Query  Window,  DFQL  will  check 
whether  or  not  the  query  in  the  drawing  aiea  of  this  Queiy  Window  has  been 
changed  since  last  Save.  If  there  are  new  changes  since  last  Save,  a  dialog  box  pops 
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up  asking  the  user  if  he  want  to  save  or  not.  The  user  should  click  either  Discard  or 
Save  in  order  to  proceed.  This  precaution  agrees  with  Interface  Principle  5;  Be 
able  to  prevent  severe  problem  from  happening. 

3.  Edit 

The  Edit  menu  as  shown  in  Figure  III.8  is  also  a  standard  Macintosh  menu. 
It  provides  the  text  editing  functions  of  Cut,  Copy,  Paste,  and  Clear.  They  are 
available  whenever  the  user  is  editing  text  items. 


UserOps  Option...  Info  Special  LUindoio 
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Figure  III.8  Edit  Menu 


The  Delete  item  deletes  the  selected  object(s).  The  L’ndo(all)  item  recovers 
the  deleted  object(s)  and  put  them  back  to  the  drawing  area.  This  feature  is  based  on 
Interface  Principle  3:  Be  able  to  recover  from  the  unintended  or  erroneous 
operation.  Undo(ail)  is  only  active  immediately  following  the  deletion  of  object(s). 

4.  UserOps 

The  UserOps  menu  as  shown  in  Figure  III.9  is  designed  for  manipulating 
user-defined  operators.  The  New  menu  item  is  to  open  the  Operator  Definition 
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Window  so  that  the  user  can  define  new  user-defined  operators.  The  Delete  menu 
item  allows  the  user  to  delete  existing  user-defined  operators  from  the  DFQL 
interpreter.  When  Delete  is  selected,  the  user  is  presented  with  a  dialog  box 
containing  a  scrolling  list  of  user-defined  operators,  as  shown  in  Figure  III.  10.  When 
the  desired  operator  is  selected,  by  either  double-clicking  on  its  entry  or  single¬ 
clicking  on  its  entry  and  then  pressing  the  Select  button  next  to  the  scrolling  list. 
Once  an  user-defined  operator  is  deleted,  it  will  disappear  from  both  the  scrolling 
list  of  the  Help  Window  and  the  UsrOpr  pop-up  menu  list  in  Query  Window  and 
Operator  Definition  Window.  The  View  menu  item  allows  the  internal  structure  of 
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Figure  III.9  UserOps  .Menu 


an  existing  user-defined  operator  to  be  displayed.  When  this  item  is  selected,  the  user 
is  provided  a  selection  dialog  box  as  .shown  in  Figure  III.l  1 .  After  the  user  chose  one 
of  the  existing  user-defined  operators  from  the  box,  an  User-Defined  Operator 
window  shows  up  and  displaying  the  internal  structure  of  that  selected  user-defined 
operator.  An  example  of  this  display  is  shown  in  Figure  III.  12.  This  display  is 
especially  useful  if  the  user-defined  operator  was  provided  by  someone  else.  The 
user  is  not  allowed  to  modify  the  internal  structure  of  user-defined  operator.  In  this 
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Figure  III.IO  Selection  Box  for  User-Defined  Operator  Deletion 


Figure  II  1. 11  Selection  Box  for  User-Defined  Operator  Viewing 


Figure  111.12  User-Defined  Operator  Window 


way  the  integrity  of  the  operator  is  preserved  while  still  allowing  some  access  to  the 
internal  for  the  user's  puipose. 

5.  Options... 

This  menu,  as  shown  in  Figure  III. 13,  is  imported  from  (Clark,  1991).  We 
did  not  introduce  any  new  features  to  it.  All  of  the  items  provided  in  Option...  menu 
are  toggle  items.  When  the  item  is  active,  or  “turned  on”,  a  check  mark  is  presented 
next  to  the  item.  For  example,  in  Figure  111.13  the  Sound  item  is  turned  “on”, 
whereas  the  Display  Last  and  Show  SQL  are  “off’.  When  the  Display  Last  is 
turned  on,  the  output  of  the  last  DFQL  operator  executed  will  be  displayed  in  the 
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Query  Resu’  '  Window  when  the  quei7  is  run.  This  is  useful  when  incrementally 
constructing  queries  because  it  causes  the  display  of  the  results  without  having  to 
use  a  display  operator.  Show  SQL  causes  the  intermediate  SQL  code  that  is 
generated  from  the  DFQL  query  graph  to  be  displayed  in  the  Query  Results  Window 
along  with  the  results  of  the  query.  This  display  can  be  used  to  troubleshoot  any 
execution  errors  that  are  not  directly  apparent  from  the  DFQL  query  graph.  Also, 
this  option  allows  the  DFQL  interpreter  to  be  used  as  a  translator  in  which  a  DFQL 
query  is  input  and  a  DFQL  query  is  output  which  could  then  be  run  on  any  SQL 
database  system.  When  selected,  the  Sound  option  causes  certain  easily 
recognizable  sounds  to  be  played  at  different  key  points  during  processing  of  the 
query. 


File  Edit  UserOpsIMlMiMInf^pecial  lUindouj 
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Figure  IIL13  Option...  Menu 


6.  Info 

The  Table  item  in  the  Info  menu,  as  shown  in  Figure  III.  14  allows  the  user 
to  retrieve  information  about  what  attributes  exist  for  tables  in  any  given  relation  in 
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the  database.  When  Table  is  selected  a  selection  dialog  box  (Figure  III.  15)  is 
displayed  from  which  the  user  can  choose  which  table  he  is  interested  in.  This  action 
will  bring  up  a  dialog  box  displaying  the  attributes  of  the  selected  table  as  shown  in 
Figure  111.16.  The  Help  menu  item  opens  the  Help  Window.  We  will  cover  all  the 
details  about  Help  Window  in  a  specific  section  later. 
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Figure  111.14  Info  Menu 


7.  Special 

This  menu  (Figure  111.17)  is  also  the  original  work  of  (Clark,  1991).  The 
only  item,  ORACLE*Shell  stars  up  a  separate  application  to  provide  the  user  direct 
access  to  the  backend  DBMS  (in  this  case  ORACLE).  Since  this  separate  application 
is  not  our  concern  in  this  presentation,  so  we  do  not  get  into  its  details. 

8.  Window 

There  is  only  one  menu  item.  Cascade  Win  (Figure  III.  18)  in  Window 
menu.  As  the  user  proceeds,  there  may  be  several  windows  opened  on  the  computer 
screen  at  the  same  time.  Some  of  them  may  be  overlaid  by  the  others.  When 
Cascade  Win  is  selected  or  its  equivalent  key  combination,  Command«W  is 
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Figure  111.15  Selection  Box  for  Table 


TABLE:  DEPT 

COLUMN  NAMES: 
DEPTNO,  DNAME,  LOC 


Figure  111.16  Table  Information 
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File  Edit  UserOps  Option...  Info 
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Figure  111.17  Special  Menu 

pressed,  all  the  windows  will  be  relocated  as  the  example  shown  in  Figure  III.  19  so 
the  banners  of  all  windows  can  be  seen.  This  feature  allows  the  user  to  easily  activate 
a  completely  overlaid  window. 


v  File  Edit  UserOps  Option...  info  Special 
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Figure  III.18  Window  Menu 


E.  HELP  WINDOW 

There  are  two  ways  to  open  the  Help  Window  as  we  described  before:  double¬ 
clicking  on  an  operator  displaying  in  the  drawing  area  and  selecting  menu  item  Help 
from  menu  Info.  Upon  opening  Help  Window,  if  we  want  to  view  the  descriptions 
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Figure  III.19  Cascaded  Windows 


of  any  other  specific  operator  in  the  operator  list,  we  can  simply  click  that  operator 
in  the  scrolling  list,  the  description  of  that  selected  operator  will  be  provided  on  the 
right.  This  feature  agree  with  Interface  Principle  1:  Be  able  to  provide  more 
information  when  asked.  Interface  Principle  2:  be  able  to  display  multiple 
information  at  the  same  time  and  Interface  Principle  4:  Be  able  to  perform  the 
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same  operation  in  more  than  one  ways.  In  fact  in  order  to  open  the  Help  Window, 
we  do  not  even  need  to  double  click  on  any  operator.  We  can  simply  select  the  menu 
item  Help  from  menu  Info  whenever  we  need  to  consult  the  help  message.  Once  the 
Help  Window  is  opened,  we  can  view  the  description  of  any  existing  operator. 

It  is  possible  for  the  user  to  find  that  the  description  of  user-defined  operators 
in  the  Help  Window  need  to  be  modified  after  the  operator  is  defined.  To  modify  the 
descriptions,  the  user  can  double-click  the  specific  operator  whose  description  is  to 
be  modified  to  open  an  editor  and  enter  what  description  appropriate.  Upon 
completion  of  the  modification,  clicking  the  OK  button  will  save  the  new 
description  of  that  operator.  This  feature  supports  Interface  Principle  3:  Be  able  to 
recover  from  the  unintended  or  erroneous  operation.  Since  the  primitive 
operators  are  basic  set  of  operators,  DFQL  does  not  allow  their  descriptions  to  be 
modified.  So  double-clicking  on  the  primitive  operators  cause  nothing  happened. 
Interface  Principle  6:  Be  able  to  prevent  modifications  that  are  not  supposed  to 
be  made  is  honored  by  this  feature. 
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IV.  PROGRAPH  AND  OBJECT-ORIENTED  PROGRAMMING 


A.  LANGUAGE  -  PROGRAPH 

Since  the  previous  DFQL  interpreter  was  implemented  in  Prograph  of  version 
2,02,  to  make  things  consistent  and  to  import  some  of  the  previous  code  into  our  new 
implementation,  we  decide  to  use  Prograph  as  our  programming  tool.  Another 
reason  to  use  Prograph  is  that,  as  stated  in  (TGSS,  Tutorial,  1990,  chapt.  1), 
Prograph  integrates  four  key  trends  emerging  in  computer  science: 

•  Visual  programming. 

•  Object-oriented  programming. 

•  Supporting  dataflow  specification  of  program  execution. 

•  Providing  application  building  toolkit. 

1.  Visual  Programming 

Contrary  to  text-based  programming,  visual  programming  uses  graphical 
operations  to  accomplish  the  programming  task.  Figure  IV.  1  shows  the  definition  of 
methods  newPerson,  setAttributes  and  introduce  for  class  Person.  In  method 
newPerson,  the  hexagon-shaped  operation  creates  an  instance  of  a  specified  class 
object  (in  this  case  a  Person).  This  newly  created  Person  then  flows  into  the 
operation  named  setAttributes  which  is  a  method  defined  in  class  Person,  After 
attributes  being  set  by  the  method  setAttributes,  the  Person  with  his  attributes  set 
flows  into  the  operation  named  introduce,  which  is  also  a  method  defined  in  class 
Person  to  have  the  new  person  self-intioduced.  Method  setAttributes  asks  the  user 
to  enter  the  person’s  name  and  where  the  person  is  from,  then  assigns  those  two 
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Figure  IV.l  Methods 
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personal  data  from  the  user  as  the  values  of  the  new  person’s  attributes,  name  and 
where  from?.  The  new  person  introduces  himself  in  method  introduce. 

There  are  four  ways  of  method  reference  in  Prograph:  The  form  of  context- 
determined  method  reference  is  “//method”.  This  reference  indicates  that  the  named 
method  can  be  found  in  the  same  class  as  the  method  containing  (calling)  this  named 
method.  In  method  newPerson,  Figure  IV.  1,  method  setAttributes  is  referenced  in 
this  form.  The  form  of  explicit-class  method  reference  is  “classname/method”. 
Method  introduce  is  referenced  in  this  form.  The  third  form.  Universal  method 
reference,  is  “method”.  The  containing  method  looks  for  the  method  in  the 
Universal  methods  pool.  The  last  form  is  data-determined  method  reference,  “/ 
method”.  Prograph  looks  for  the  method  in  the  class  to  which  the  object  arriving  at 
the  first  input  terminal  of  the  method  belong.  This  powerful  method  referencing 
form  supports  polymorphism  of  object-oriented  programming  and  late  binding. 
Different  classes  can  each  havv  a  method  of  the  same  name  with  totally  different 
function.  When  a  method  is  referenced  in  this  foim,  Prograph  does  not  know  from 
which  class  the  specified  method  can  be  reference  until  the  class  object  arrives  on 
the  input  terminal  of  the  specified  method  at  runtime.  That  is  why  we  say  that  it 
supports  late-binding. 

2.  Object-Oriented  Programming 

Prograph  provides  a  good  foundation  for  object-oriented  programing, 
system  classes.  Each  class  has  two  components;  attributes  and  methods. 
Attributes  identify  instances  of  classes.  By  passing  messages  (calling  methods)  to 
objects  (instance  of  class),  we  can  make  them  act  accordingly.  In  prograph,  objects 
of  same  categories  are  group  into  classes,  that  is  to  say  that  a  class  is  an  abstract 
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description  of  a  collection  to  similar  objects.  In  object-oriented  programming, 
objects  communicate  by  passing  messages.  The  situation  is  similar  in  Prograph  but 
objects  flow  into  operations  to  initiate  some  actions,  rather  than  stationary  objects 
sending  messages  back  and  forth  (TGSS,  Tutorial,  1990,  chapt.  4).  Figure  IV.  2 
shows  a  class  window  displaying  the  classes  hierarchy,  the  attributes  and  methods 
window  of  class  Person.  In  Figure  IV.  1,  we  have  shown  one  way  to  assign  attribute 
values  and  to  pass  message  asking  the  person  to  introduce  himself/herself.  The  line 
between  classes  represent  inheritances.  For  example,  classes  Student  and 
Instructor  are  both  descendants  of  class  Person  They  both  inherit  all  the  atuibutes 
and  behaviors  (methods)  of  their  ancestor  Person.  But  they  can  have  their  own 
additional  attributes  and  methods  (Figure  IV.  3).  In  atuibute  window.  Figure  IV.3, 
there  is  a  downward  anow  in  each  inherited  attribute  icon.  Method  oveiriding  is  also 
allowed  in  Prograph.  For  example  class  Instructor  has  its  own  method  introduce 
whose  functionalities  can  be  totally  different  from  Person's. When  an  instance  of 
Instructor  is  “asked”  to  introduce  himself,  instead  of  referencing  the  method 
introduce  in  class  Person,  the  one  in  class  Instructor  is  to  be  referenced.  But  since 
class  Student,  has  no  its  own  method  introduce,  so  when  an  instance  of  class 
Student  is  “asked”  to  introduce  herself,  the  inherited  method  introduce  defined  in 
its  parent  class  Person  is  to  be  referenced.  Programmers  can  also  make  their  created 
classes  descendants  of  system  classes  so  a  great  deal  of  effort  can  be  saved. 

3.  Dataflow  Programming 

In  Prograph,  each  operation  can  have  zero  or  moie  input  terminals  and  zero 
or  more  output  roots  representing  by  small  circles  attaching  to  the  top  or  bottom  of 
operations  (Figure  IV.4).  Data  flow  along  arcs  connecting  terminals  and  roots.  When 
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Figure  IV.2  Class  Hierarchy  and  Class  Components 
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all  required  input  data  become  available  at  an  operation’s  terminals,  the  operation 
can  not  execute  or  fire.  Specific  order  of  execution  is  not  prescribed  in  Prograph 
programs.  This  situation  implies  that  concurrent  execution  of  several  operations  is 
likely  to  occur.  To  enforce  the  order  of  execution,  synchros  are  provided  as  shown 
in  Figure  IV.4.  In  Figure  rv.4,  there  is  a  direct  arc  connecting  the  root  of  operationl 
and  one  terminal  of  operationl,  so  operation  2  must  execute  after  the  execution  of 
operation  1.  Same  situation  between  operation  1  and  operation  3.  But,  since  there 
are  no  direct  arc  between  operation  2  and  operation  3,  so  they  can  execute 
whenever  their  required  input  data  are  available.  Execution  order  of  operation  1  and 
operation  2  is  not  prescribed  without  the  synchro.  With  the  synchro  emerging  in 
Figure  rv,4,  the  execution  of  operation  3  is  enforced  to  wait  until  the  execution  of 
operation  2  is  done.  In  method  setAttributes,  Figure  IV.l,  we  used  a  synchro  to 
ensure  that  a  person’s  name  was  asked  before  where  he/she  is  from  is. 

By  combining  the  dataflow  specification  of  program  execution  and  some 
powerful  debug  facilities.  Prograph  allows  programmers  to  debug  programs  by 
inspecting  the  data  flowing  in  the  programs  from  debug  mode.  With  the  inspection 
of  the  dataflow,  programers  can  see  how  programs  work  and  why  it  does  not  work 
the  way  as  expected  if  there  are  some  eiTors  in  the  programs. 

4.  Application  Building  Toolkit 

The  application  building  toolkit  in  Prograph  supports  independent 
specification  and  management  of  the  interface  through  high-level  tools  and 
facilities.  For  example,  the  application,  menu,  window,  and  several  window  item 
editors  are  some  powerful  and  easy  to  use  tools  provided  in  Prograph,  application 
editor  (Figure  1V.5)  serves  as  a  library  of  menus  and  windows.  The  menu  editor 
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Figure  IV.4  Terminals,  Roots,  Arcs  and  Synchro 


(Figure  rV.6),  window  editor  (Figure  IV.7),  and  window  item  editors  (Figure  IV.8) 
are  used  to  specify  the  “look  and  feel”  of  the  menus  and  windows  created  and 
organized  using  the  application  editor.  So  instead  of  developing  the  windows, 
menus,  and  their  items  we  need  in  the  DFQL  user-interface  from  scratch,  we  can  just 
specify  some  essential  infoimations  in  each  relevant  editor  and  the  application 
builder  will  creates  what  we  need  according  to  the  informations  we  specified.  To 
refine  any  portion  of  them,  we  just  return  to  the  relevant  editor  and  respecify  some 
relevant  informations.  No  recoding  and  recompilation  needed. 

Since  there  are  some  new  features  and  facilities  added  to  the  2,02  version, 
so  our  program  is  implemented  in  Prograph  of  version  2.5  (e.g.,  the  pop-up  menu 
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Figure  IV.5  application  Editor 

we  used  in  the  Query  Window  is  a  new  added  facility  to  version  2.5).  We  do  not 
intend  to  get  into  the  details  of  Prograph.  The  following  references  by  The  Gunakara 
Sun  Systems  Limited  (TGSS)  are  recommended  for  those  w'ho  aje  interested  in. 


Prograph:  Tutorial,  second  printing,  1990. 
Prograph:  Reference,  second  printing,  1990 
Prograph:  2.5  Updates,  first  printing,  1991. 
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B.  WHY  OBJECT-ORIENTED  PROGRAMMING 

Object-oriented  programming  is  often  referred  to  as  a  new  programming 
paradigm  (Budd,  1991).  In  Clark’s  DFQL  interpreter,  object-oriented  approach  was 
attempted.  But  after  a  careful  examination  of  Clark’s  program,  we  found  that  some 
major  object-oriented  programming  features,  such  as  responsibility  driven, 
information  hiding,  and  modularity  do  not  play  their  role.  And  the  program  is  also 
tightly  interconnected  by  heavily  using  the  explicit-class  method  reference. These 
drawbacks  restrict  the  reusability  of  his  program,  so  in  order  to  use  some  methods 
in  his  program  we  spent  some  significant  effort  to  modify  and  re-modularize  his 
original  code.  Because  of  this  experience  we  decide  to  approach  our  new 
development  from  object-oriented  view  so  that  our  code  may  be  more  reusable, 
portable,  and  maintainable. 

During  the  examination  and  modification  of  Clark’s  program,  we  also  found 
many  attractive  features  of  OOP  can  be  adopted  to  model  our  new  DFQL  interface. 
In  our  view,  DFQL  interface  consists  of  objects  like  Query  Window,  drawing  area 
(a  canvas  in  which  we  draw  our  query)  and  operators,  etc.  These  objects  are 
manipulated  in  response  to  events,  such  as  the  clicking  or  dragging  on  the  body  of  a 
DFQL  object  cause  the  object  being  selected  or  dragged.  This  awareness  also 
encouraged  us  to  do  experiment  of  object-oriented  programming. 

C.  Evaluation  Of  Object-Oriented  Programming 

In  this  section,  we  aie  going  to  discuss  some  features  of  object-oriented 
programming  we  applied  to  our  new  development  of  DFQL  interface  and  some 
benefits  we  have  gotten  through  the  whole  design  process. 
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1.  Benefits  of  Responsibilities-Driven,  Class,  and  Inheritance 

To  organize  or  discover  classes,  we  need  to  take  the  responsibilities  of  each 
potential  class  into  consideration.  Clear  assignments  of  responsibilities  increase  the 
degree  of  independence  of  classes  thus  increase  the  degree  of  information  hiding 
and  reusability.  When  we  make  an  object  responsible  for  a  specific  action,  we  can 
expect  a  certain  behavior  the  object  is  to  behave  as  we  passing  the  request  to  it.  The 
higher  the  degree  of  behaviors  of  objects  we  can  expect,  the  easier  we  can  debug  our 
program  when  errors  occur  and  the  easier  to  expend  our  program  by  assigning  more 
appropriate  responsibilities  to  appropriate  classes  without  causing  intensive 
modification  to  the  program  has  been  existing  or  importing  unexpected  interferences 
between  new  code  and  old  code. 

Figure  IV.9  shows  the  classes  hierarchy  of  our  program.  The  white-colored 
classes  are  system-provided  while  the  black-colored  classes  are  our  created  ones. 
Each  class  representing  one  category  of  objects  encapsulates  informations  and 
functionalities  within  its  attributes  and  methods.  This  classes  hierarchy  is  organized 
after  the  following  analysis:  Class  Query  Window  represents  the  main  window 
(also  named  Query  Window)  with  the  responsibilities  of  detecting  and  handling  the 
mouse  click  events  on  its  item  such  as  button  close  box,  etc.,  creating  new  Query 
Windows,  setting  attributes  of  new  created  Queiy  Windows,  loading  query  files  onto 
Query  Windows  saving  query  files  to  disks  and  closing  Query  Windows,  etc..  Class 
Query  Object  represents  all  query  objects.  Classes  Text  Object  and  Operator 
represent  text  objects  and  operators  respectively.  Because  they  are  both  query 
objects  so  we  make  them  the  descendants  of  class  Query  Object  to  inherit  the 
attributes  and  methods  we  defined  in  class  Query  Object.  Since  operators  can  also 
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Figure  IV.9  Classes  Hierarchy 


be  grouped  into  primitive  operators  and  user-defined  operators,  so  we  make  classes 
Primitive  and  UserOpr  the  descendants  of  class  Operator  representing  primitive 
operators  and  user-defined  operators  respectively.  Class  Query  Object  and  its 
descendant  classes  are  responsible  for  maintaining  and  creating  query  objects.  Class 
DFQLCanvas  represen^j  the  drawing  area  (the  drawing  area  just  like  a  canvas) 
within  which  we  “draw”  our  queiy.  It  is  responsible  for  detecting  and  handling  all 
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kind  of  mouse  click  events  in  the  drawing  area  and  acts  accordingly,  drawing 
objects,  dragging  objects,  and  deleting  objects.  Class  InputBox  represents  the 
“input  box”  within  which  users  type  in  the  text  for  the  later  creation  of  query  objects. 
It  is  responsible  for  displaying  the  “inputbox”  at  where  users  click  the  mouse  and 
reading  text  that  users  type  in  from  the  keyboaid.  Classes  QueryResults, 
UsrOprWin,  Printer  and  its  descendant  DFQLPrinter,  Line,  and  Help  are  created 
by  following  the  similar  analysis. 

Assuming  the  user  wants  to  create  an  operator  by  selecting  one  from  either 
pop-up  menus  Primitive  or  UsrOpr,  then  when  the  event  of  clicking  mouse  in  a 
pop-up  menu  and  selecting  one  operator  from  the  menu  is  detected  by  Query 
Window,  Query  Window  passes  message  requesting  the  creation  of  an  operator 
with  the  name  specified  to  class  DFQLCanvas.  Upon  receiving  the  request. 
DFQLCanvas  does  some  prelimilaiy  actions  and  then  passes  the  same  request 
received  from  Query  W'indow  to  class  Primitive,  Primitive  then  check  its 
primitive  operator  list  whether  there  is  one  with  the  same  name  passed  in  or  not.  If 
there  is  one.  Primitive  returns  the  matched  operator  back  to  DFQLCanvas.  If  there 
is  none  matched,  the  same  message  is  delivered  to  class  UserOpr  to  create  an  user- 
defined  operator.  After  the  operator  is  returned,  DFQLCanvas  draws  it  in  the 
drawing  area.  The  ellipses  in  Figure  IV.  10  highlight  the  process  of  message  passing. 

VVe  make  each  class  an  encapsulation  of  absuactions  having  two  faces. 
From  the  outside,  a  user  of  that  abstract  encapsulation  S'  a  collection  of 

methods  which  define  the  behavior  of  the  encapsulation  actions.  On  the 

internal  side,  attributes  (some  people  use  the  term  i.  tables,  but  for 

consistency,  we  will  use  attributes  through  this  thesis)  ai\  to  maintain  the 


internal  state  of  the  object.  In  the  above  example,  by  using  responsibility-driven,  we 
do  not  allow  classes  to  interfere  or  modify  attribute  values  of  other  classes  because 
we  view  changing  attribute  values  as  the  internal  affair  and  all  of  them  must  be 
maintained  internally  by  the  class  instance  itself  under  any  circumstances.  This 
measure  makes  a  program  less  enor-prone  and  ease  the  maintenance  of  a  program. 
Also,  the  information  hiding  rule  is  observed  by  the  careful  responsibility 
assignments.  For  example,  DFQLCanvas  issues  requests  of  query  object  creation 
to  classes  Primitive  without  knowing  how  they  are  created. 

The  clear  division  of  classes  helps  us  design  a  well  structured  and 
modularized  program.  The  hieraichical  organization  also  helps  us  to  remember  the 
whole  structure  of  our  program  and  the  relationship  between  classes  easier  and 
better.  Since  many  methods  are  inherited  by  the  descendant  classes  from  their 
ancestor  classes,  we  do  not  need  to  replicate  codes  over  and  over  again.  This  feature 
shortens  the  development  lime  and  supports  information  hiding  also.  Figure  IV.  10 
shows  an  example  of  inheritance.  In  Figure  IV.  10,  when  either  class  Primitive  or 
class  UserOpr  receives  the  message  requesting  the  creation  of  an  object  from  class 
DFQLCanvas,  since  there  is  no  method  capable  of  creating  objects  defined  in  both 
classes  Primitive  and  UserOpr,  the  method  create  defined  in  their  paient  class 
Operator  will  be  referenced  as  if  it  is  defined  in  their  own  classes.  This  benefits  is 
more  significant  in  the  inheritances  of  our  created  classes  from  system  provided 
classes.  Foi  example,  by  making  classes  Query  Window,  QueryResuIts,  and 
UsrOprWin  v  descent  nts  of  system  provided  class  Window,  we  can  simply  use 
the  methods  ^  f  e.  Activate,  and  Idle  defined  in  class  Window  without 
knowing  how  uiey  .  .  .plemented. 
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Figure  IV. 10  Process  of  Message  Pas^oi 
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2.  Benefits  Polymorphism  and  Late  Binding 

Polymorphism  is  an  feature  to  send  the  same  message  to  instances  of 
different  classes.  It  enhances  the  readability  of  software  and  leads  to  an  easier 
extension  of  code.  Figure  IV.  11  shows  an  example  of  Polymorphism.  When  we 


Fi  iV.ll  Example  of  Polymorphism 
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choose  menu  item  Quit  from  menu  File,  method  Quit  defined  in  class  Menu  is 
called.  When  this  method  executes,  a  list  of  windows  opened  flows  from  the  right 
output  terminal  of  operation  windows  to  method  Close  which  is  of  the  Data- 
determined  method  reference  form.  As  we  mentioned  in  last  section,  all  windows  are 
viewed  as  instances  of  different  classes,  so  when  the  message  Close  is  sent  to  them, 
they  will  behave  according  to  the  Close  method  defined  in  their  class  or  ancestor 
class.  Because  all  windows  are  subclasses  of  system  class  Window,  so  except 
Query  Window  which  need  to  save  the  queiy  file  before  closed  if  the  content  of  the 
query  file  has  been  changed),  all  window  will  close  by  calling  method  Close  defined 
in  class  Window.  The  method  Close  defined  in  class  Query  Window  as  shown  in 
Figure  IV.  11  overrides  the  method  Close  in  the  paient  class  Window  by  having  the 
same  name  and  different  behavior.  It  first  save  the  query  file  which  has  been  changed 
if  the  user  desired  and  then  calls  the  method  Close  defined  in  class  Window  (the 
upward  arrow  means  method  Close  in  the  supper  or  parent  class  is  to  be  called).  In 
this  example,  we  see  the  same  message  Close  sending  to  instances  of  different 
classes  causes  them  to  behave  differently.  We  also  see  that  late  binding  utilized  in 
this  example.  The  proper  methods  Close  to  be  referenced  is  unknown  until  the 
instances  arrive  (i.e.,  until  run-tome).  This  makes  the  high-level  softwaie  design 
more  flexible. 

The  overriding  we  saw  in  last  example  is  just  in  form  of  polymoiphism. 
Another  form  is  overloading  which  makes  the  flow  of  softw  -e  p  ■  'cution  easier  to 
be  followed  by  users.  Figure  IV.  10  shows  how  the  methods  t  fined  in  classes 

Query  W'indow,  DFQLCanvas,  and  Operator  aie  refere:  e  overload  the 
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method  name  create  so  the  way  an  operator  is  created  easier  to  be  understood  and 
the  code  is  also  easier  to  be  read. 
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V.  CONCLUSION 


A.  LESSON  LEARNED 

some  lessons  we  leained  in  our  development  of  this  new  DFQL  interface  can  be 
stress  in  two  aspects;  user  interface  and  object-oriented  programming. 

1.  User  Interface  Aspect 

As  an  application  designer,  we  need  to  originate  all  the  ideas  from  the  users’ 
point  of  view.  So  human  factors  need  to  be  taken  into  consideration.  Our  experience 
is  that  some  established  principles  like  those  we  listed  in  Chapter  I  need  to  be 
followed  all  the  time.  W'e  also  evaluate  some  human  factors  such  as 


•  lon^  does  it  take  a  regular  user  to  learn  this  new  application. 
We  need  to  provide  users  a  consistent,  well-explained,  and  easy-to- 
use,  and  easy-to  leain  tool  so  they  will  not  get  confused  or  frustrated 
by  the  complexities  of  tlie  tool. 

•  What  kind  of  errors  may  be  made  by  users.  Taking  this  factor  into 
consideration  leads  to  a  design  of  careless-proof  or  even  fool-proof 
application. 

•  What  decree  do  users  maintain  their  knowledge  about  the 
application  after  a  period  of  time.  To  increase  the  degree,  the 
consistency  must  be  enforced  and  on-line  help  messages  must 
always  be  available. 

2.  Object-Oriented  Programming  Aspect 

The  following  is  a  list  of  lessons  we  learned  from  the  object-oriented 
programming  aspect: 


Each  class  is  responsible  for  one  task  or  .s 
tasks  and  allow  attribute  values  to  be  modifo 
its  own  class.  This  reduces  the  degree  of  ) 


tuitively  similar 
lintained  only  in 
nection  between 
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classes  and  makes  each  class  cohesive  and  modular  so  later 
modification  and  extension  is  easier. 

•  Avoid  writing  long  methods.  Try  dividing  a  task  into  several  subtasks 
which  can  be  implemented  as  clearly  defined  methods.  This  also 
makes  later  modification  and  extension  easier  and  increases  the 
reusability. 

•  Properly  use  polymorphism  to  make  program  easy-to-read.  This 
makes  programs  more  symmetric  and  easier  to  be  understood. 

•  Avoid  using  explicit-class  method  reference.  Explicit-class  method 
reference  makes  methods  tightly  interconnected  so  when  a  class 
name  is  changed,  we  have  to  change  all  references  in  the  whole 
program.  This  is  eiTor  prone  and  time  consuming. 

•  Properly  use  abstract  superclass  to  support  information  hiding  and 
inheritance.  We  discussed  many  benefits  of  information  hiding  and 
inheritance.  Proper  use  of  superclass  allows  the  programer  to 
concentrates  on  the  further  development  without  paying  attention  to 
the  low-level  details  of  the  referenced  methods. 

B.  SUMMARY 

This  thesis  provides  an  improved  user  interface  of  DFQL  originally  introduced 
by  Card  J.  Clark  and  C.  Thomas  Wu  in  1990.  In  this  thesis,  we  eliminated  the 
shortcomings  of  user  interface  pointed  out  in  their  paper  and  added  some  new 
features  to  it.  Now,  this  new  DFQL  user  interface  allows  users  to  create  DFQL 
objects  simply  by  clicking  the  mouse  and  then  entering  the  text  right  on  the 
computer  screen.  Some  tedious  operations  in  the  previous  version  of  DFQL  such  as 
deleting  an  object,  selecting  an  user-defined  operator  have  been  simplified  in  our 
new  implementation.  We  also  make  on-line  help  messages  easy  to  get  and  allow 
information  d;  •  window  such  as  Help  window.  Query  Results  window  and 
User-Defined  Operas  r  window  to  co-exist  at  the  same  time  when  users  are 
constructing  their  queries  in  Query  Window.  This  makes  more  reference 
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information  available  at  the  same  time.  We  also  allow  users  to  open  Query 
Windows  as  many  as  they  want  and  define  user-defined  operators  consecutively. 
The  content  of  help  messages  of  user-defined  operators  entered  by  users  can  also  be 
modified  easily. 

In  addition  to  the  new  features  we  added  to  the  DFQL  user  interface,  we  also 
did  an  object-oriented  programming  experiment  on  this  new  implementation.  The 
main  techniques  of  object-oriented  programming  such  as  message  passing,  class, 
responsibility-driven,  inheritance,  and  polymorphism  are  used.  The  benefits  of  these 
techniques  are  also  evaluated. 
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APPENDIX 


Only  the  source  codes  we  developed  are  presented  in  this  thesis.  The  original 
codes  of  system  provided  classes  are  not  printed. 
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^Menu/Quit  1:1 


Qje'-y  W.racw  Wed.  Vay  2C.  -  292  5  D9  PM 


^Menu/delete  1:1 


X 


^own«r^  OFQLCanva* 
o  ■  ■  ■  ■  *~ 


^tind-itan^ 

^  7 

^/dalata^ 


Oue^  Window  Wed.  Vay  20.  1992  6  09  PM 


^Query Results /shouiQuery Results  2:2 


^QueryResults/shoujQueryResults  1;2preuious  luin  loc  1:2 


^QueryHesults/shouiQueryResults  l:2preuious  uiin  loc  2:2 


Query  WiOaow  Tue,  May  19.  1992  11.01  PM 


Qu«fy  Window  May  1992  ll:0i  PM 


t^QuerylUindoiu/clear  1:1 


^Queryllfindoiu/Close  1:1 


II  ths  window  to  tie  closed  is  ol  lype  ‘OueryWindow* 
and  the  contents  ol  the  canvas  m  mat  window  nas  Been 
changed(i.e.,lile  changed)  prompt  the  user  to  save  it  betore 
closing  the  window. 


$1.  Operator  Delinition  Window 


§1.  has  been  changed  Save  it? 
§2.  The  content  In 


I 


Query  W.ndow  Wed,  May  20.  1092  5  23  PW 


^Querylitindoui/create  1:1 


This  method  is  to  handle  the  pop  up  menu 
selection.  An  oOiect  will  be  created 
according  tp  the  pop  up  menu  item  selected. 


^QueryLUindoui/actiuateQlil  1:1 


«OueryWindow» 


mm 


[^update  manual 


It's  possible  to  activate  a  Ouery  Window  with 
other  types  of  window  being  Irontmost.  So  it's 
necessary  to  update  menu. 


^QuerylUindouj/actiuateQtli  1:1update  menu  1:1 


\mssm,\ 


ccccc«l  B  update  Edil^l 


Que-,  W'r>sow  Wed.  May  20.  1992  5  23  PM 


^Querylllindoui/actiuateQlU  1:1  draw  1:1 


^QuerylUindotu/actiuateQUI  I  :l  update  menu  1:1  enable  menu  1:1 


^QueryUlindoui/actiuateQUI  1:1update  menu  1:1update  Edit  1:1 


^QuerylUindoui/actiuateQlU  IMupdate  menu  l:1update  File  1:1 


OQueryUlindoui/actiuateQUJ  l:1update  menu  1:iupdate  Edit  1:lactiuat  delete  1:1 


^QueryUiindoui/actiuateQlU  1:1update  menu  l:1update  Edit  1  :l deactiuate  others  1:1 


|l.  (’Undo  (aS)'  ‘Cur  ‘Copy’  ‘Ooar’  ’Pasta') 


Quary  Window  Wad.  May  20.  1992  5  24  PM 


^QueryUJindoui/actiuateQlU  IMdraiu  l:1draui  input  boK  if  it  exists  1:1 


^QueryUlindoui/actiuateQU)  1  :t  drain  1 :1  drain  input  box  if  it  exists  1 :1  drainGenericOp  I  :l  getCenericRect  1 :1 


^QueryUlindoin/actiuateQlU  t  :l  drain  I  :l  dram  input  box  if  it  exists  1  :l  drainGenericOp  1  :l  do  dram  I  :l 


^QuerytUindouf/set-attributes  1:1  get  luindoui  location  2:2 


(SO  15) 


Query  Winaow  W»0  May  20.  '992  5  24  PM 


^Querylllindoui/set-attributes  1:1  query  win  «  *  \  1:1 


^Querylliindow/set-attributes  l.'lnew  OFQlCanuas  1:1 


CraaM  a  naw  OFOLCanvas  Ick  aach  naw  QuaryWmaow. 


Query  W^naow  Weo,  May  20.  1992  5  24  PM 


^Querytllindoiu/Key  1:2 


^salactcd  lit 


TRUE  0 


i/rtadk*y  boarci 


UMr  thouW  pr*M  'ralurn’  lo  finish  (yping. 
So  kaap  rsading  inputs  from  ksyboard  unfit 
'roturn'  it  pratssd. 


^Querytilindoui/Key  2:2 


<Wlndoi>r>  \  Evant 

>\alacttd  Itan^  Record 


OFQLCanvat 


NULL  0 


When  ‘return*  is  pressed,  create  an  gdDoPi 
according  to  the  text  the  user  typed  in. 


^QuerylUindout/Key  l;2return  pressed?  1:2 


TRUE  1  3  (xj 


^QueryUiindoui/Key  l:2return  pressed?  2:2 


^QuerylUindoiif/reset  1:1 


Clear  drawing  canvas  In  Query  Window,  empty  gdbobjlisl. 


§1.  (0  0  32000  32000) 


^QuerytUindouj/reset  i:1reset  canuas  1:1 


mnst^ 


^QuerylUindoiu/reset  l:lreset  canuas  l:1reset  neujOpCenter  1:1 


ncwOpCcnt* 


V 

Locals  ttw  nswOpCsnisf  at  the  top  of  canvas 


^QuerylDindow/saueit  1:2 


lllsnams  volS 


V^y///y/^/y/y//y/Ay/yy/^y/9irA/y/yy7\ 


Pirst  backup  tr>«  (iie  it  poss-bie.  and  then  save 
the  data  trom  areciist  mio  tiienarr.e  on  vote. 


^QueryUJindDiu/saueit  2:2 


lllanama  vol« 


If  th«  backup  operation  tailed,  then  don't 
teMO  the  new  lUe  becauee  it  couk)  write 
(war  our  praviou*  data  without  having  that 
data  backed  up. 

The  error  meesagai  tor  tailed  backup  are 
all  contained  m  Via  mkbackup  local  malhod. 


^Querylllindoiu/saueit  l:2mlcbackup  1:2 


^Querylilindotu/saueit  1 :2mlcbackup  2:2 


§1.  ‘Continuing  will  cause  this  tile  to  be  replaceoi' 
§2.  ‘  Is  not  an  apptopriale  dbinterlaca  Ille.' 


^QuerytUindoiu/saueit  1:2dosaue  1:2 

TlienamG  vcr#  -  —  - 


Query  Window  Wed.  May  20.  1992  5:24  PM 


^Querylllindoiii/saueit  l:2do$aue  2:2 


^QueryUJindotii/saueit  I:2mkbackup  1:2cklength  1:2 


Th«  nsw  lllanams  with  '.bak'  concatenated  to 
it  is  o(  a  valid  length  (<=3t)  so  conl.nue. 


^QuerylUindoiii/saueit  1 :2itnkbackup  1:2cklength  2:2 


.  Ak  - 


ParsmTex . 


?1 20S  ;  0 


Filename  with  '  bait" 
concatenated  to  it  was  too 
long  $0  generate  error 
message  and  tail  this 
operation 


StopAltrl 


Query  Window  Wed,  May  20.  1992  5  24  PM 


^QueryUJindoui/saueit  l:2mkbackup  l:2cklength  2:2 


L  Vout  HI*  wM  not  b«  MvodI' 
’  It  loo  longl* 

Sorry,  Backup  Ika  nama:  * 


^QueryUlindoiu/saueit  l:2mkbackup  1:2cksaue  1:2 


Saving  ins  bacKup  tils  isas  successlul. 


^QuerylDindoui/saueit  l:2fnkbackup  1:2cksaue  2:2 


f rom-ttc  i 


tyyy/yyyyyyyy/yyyy/yAyyy//Ay/y^A^^ 


OQueryUJindoui/loadit  1:2 


tilenams  volume 


^Ay/yy/^/yyyyy//yyAyy/yyAyyyyyAyyyy\ 


«OusryWindow» 


procsssioad 


It  t>9  Ills  has  not  been  opened 
load  the  data  from  the 
tpecilied  tile.  Procsssioad 
updates  the  gdbobiiist  and  window 
or  reports  on  any  errors  mat 
ware  generated  by  the  load. 


Query  W.nacw  Weo.  Way  21.  1992  5  2S 


^QueryUfindoui/ioadit  l:2proces$load  1:3 


^QuerylDindoui/saue  as  1:1 


Qusry  Window  Wad.  May  20.  t»92  5  24  PM 


^QuerytUindoui/saue  as  1:1  used  in  other  uiimdouis?  1:3 


<QuefyWirKJow» 


Usar  did  not  change  the 
original  tile  name. 

FALSE 


^QuerylUindoui/saue  as  1:lused  in  other  uiimdoius?  2:3 


^Querytilindoui/saue  as  1;lused  in  other  utimdOLUs?  3:3 


Qu®ry  Wtr.do»¥  Wed.  May  20.  1992  5  25  PM 


^QuerylUindoiu/readteHt  1:1 


^QueryUlindoui/readteKt  1:1lastchar  1:1 


^QuerylUindotu/openloop  1:1 


^QueryUJindoui/saue  1:1 


Quory  Window  Wod.  May  20.  1992  5  25  PM 


Raad  kayboard  and  aniarga  tha  Input 
box  according  to  tha  langm  of  tha  laxt. 


^InputBoM/readkeyboard  l:1re$ize  input  boK  1:lget  string  width  I;1 


Gutfry  Window  Tua,  May  19.  1992  0  12  PM 


^InputBoK/readkeyboard  Irtresize  input  boK  T:I$et  new  size  f  :l 


OOFQLCanuas/updategdbteKt  l:tget  neuitCKt  &  center  I:Icenter-of-mainrect  l.’lhoriz  1:1 


^OFQLCanuas/updategdbteKt  l:lget  netuteKt  C-  center  l:lcenter-of-nnainrect  l:luert  1:1 


Query  Window  Wed,  May  20.  1992  6  34  PM 


^OFQLCanuas/create  1:2 


Quary  Window  Wad.  May  20.  1992  6  34  PM 


OOFQLCanuas/create  1:2set  file  changed?  1:1 


^OFQLCafluas/create  t:2getobject  2:3 


taxi  dispLagtrinslnum 


W/ 


OOFQLCanuas/create  1:2getobject  3:3 


Query  Window  Wed.  May  2C.  1392  6.34  PM 


^DFQLCanuas/create  l:2add-to-gdbobJlist  1:1 


^OFQLCanuas/create  t:2init  inputboK  1:1 


input  boi 


"  X 

^/Init  InpulbojS 


e7w^’m//’/PMw.>y.r77^/w77^ 


^DFQLCanuas/create  1:2erase  input  boK  1:1getGenericRect  1:1 


^OFQLCanuas/dodrawall  1:1 


^y/y.wv>w/A' 


Query  Windcw  Wed.  May  20.  1992  6.34  PM 


^OFQLCanuas/dodraiuall  1:1locdraiuinputbar  1:2 


^uifOpfdf^ 

/  ,  , 

FALSE  [)^ 


^DFQLCanuas/dodrauiall  1:1  locdratuinputbar  2:2 

^j/drawinputb«^ 


^OFQLCanuas/getcanuas  1:1 


Applieallon 

B  OFOLCanvat 

^  Reijfns  the  canvas  Ifom 
^Und-ltan^  Query  W.ndow. 


NULL  0 


^DFQLCanuas/rubberb  1:1 


to  connect  oOiacts  with  lines.  Uses  continuous 
draw  and  erase  routines.  Until  a  mouse  click. 

^ - 

I 


Query  Winoow  Wed.  May  20.  IM2  6.34  PM 


^OFQLCanuas/eraseline  1:1 


Erasss  a  tin*  irom  po<nii  to  pomta 
By  changing  th«  pan  moda.  Changas 
pen  oack  to  paiCopy  wnan  dona 


I 


Query  W  nooi*  Wad.  May  20,  1S92  6  3a  PM 


Draws  all  corrnactirtg  Imas  Irom  ma 
root  01  ar.  input  0b|sct. 


Ouary  Window  Wad.  May  20.  1BB2  6:3S  PM 


I 


Query  Winoow  Wed.  May  20.  1902  6:35  PM 


^OFQLCanuas/drauiinnodes  1:1 


^DFQLCanuas/doerase  l:lerasestuff  Izlinuert  if  selected  1:1 


i 


Qu«ry  Window  W«d.  May  20.  1902  6  35  PM 


^OFQLCanuas/draiuobJ  2:2 


•  c*«nd*dr«Min 


Draws  gdbopr  ob)6Ci  from  aach 
of  (h«  componant  parts. 


^OFQLCanuas/draiuobj  l:2drauj  gdbteKt  1:1 


^DFQLCanuas/draiiiobj  2:2draui  Primatiue  &  UserOpr  1:1  draw  body  &  root  1:2 


;  FranicRQundRtct 


333J3353’’- 


|1.  (DISPLAY  SDISPLAY) 


ODFQLCanuas/draiiiobj  2:2draiii  Primatiue  C-  UserOpr  1:1  draw  body  &  root  2:2 


Otaw  DISPLAY  or  SDISPLAY 


^D'^tlLCaruas/inuert  1:1 


^DFQLCanuas/deiete  1:1 


^DFQLCanuas/delete  IMdeletem  1:2 


^OFQLCanuas/delete  1  :l  deletem  2:2 


fAVM’A'AmV.' 


sSiZzzrs^zzs 


^DFQLCanuas/delete  1:ldeletem  1:2doroot  1:1 


Query  Window  Wed.  May  20.  1092  6  35  PM 


^DFQLCanuas/delete  IMdeletem  l:2doterms  1:1 


§1.  (Primitive  UserOpr) 


“«‘CCC5, 


!  rmvtaios  j 
Jri 


0  00 — 

Auumas  mat  tinea  \  y 

v»a  uta  lind-inslanca  \  ^ 

mat  whan  wa  maka  a  \ 

change  it  is  NOT  on  a  \ 
copy  but  on  the  original.  \ 


trooltlat 
0  o-S  ' 


fixrootlistr: 

r..g 


Assumes  at  least  one  root 
connection  since  we  nave  a 
terminal  tnat  ^ays  it  is  connected 
to  this  root. 


^OFQLCanuas/delete  l:1deletem  l:2doterms  Itirmuzeros  1:2 


^OFQLCanuas/delete  1:1deletem  1:2doterms  1:lrmuzeros  2:2 


^DFQLCanuas/delete  1:1deletein  1:2doterms  1 :1  TiKrootlist  1:1 


Query  Wir.dow  Wea.  May  20.  1992  6  35  PM 


^OFQLCanuas/myclick  1:1 


canvas  potnt 


>®vani  rac 


^sat  tila  cnangao^l 


|{cf®ata  it  input  box  exist jpJ3^//handla  clic^ 

Tn®  contents  of  me  wtnaow  ts  cnanged  wnen  cftCKed. 
Upon  clicking,  it  there  is  a  input  box  exists  create 
a  goDobi  according  to  the  text  m  the  input  box  before 
handling  the  click. 


^OFQLCanuas/myclicIc  l:1set  file  changed?  1:1 


^OFQLCanuas/myclick  1:lcreate  if  input  boK  euist  1 :1 


^DFQLCanuas/handle  click  2:5 


|^l»rmclicK'>3l>^ 

^^nslnum  tern*) 

II  dotarrrtc*  ck^ 

Click  on  a  tarmmal  (input  node). 


OOFQLCanuas/handle  click  3:5 


Handias  circk  tt  on  a 
fool  (Output  noae' 


^OFQLCanuas/handle  click  4:5 


*  ?  avani  f#c 


<po.nt 


y X I  [|°oi°p\jtDafC'»:n j 

Handle  click  on  tne 
input  Oar.  (Prom  add  user 
operator  siare  ) 


OOFQLCanuas/handle  click  5:5 


canvas  ?poini  avant  tac 


^n«w9^«ni*^<«kccccc««clg3,awl7naOnVjl': 


It  drawLinaOn  la  Irua  ttian  |ual  tarmlnaia  this  mathod  Esia. 

II  a  ganaric  oparalot  axitis.  craaia  a  gddotii  according  to 
Ihe  taxi  in  tha  input  Pox.  Than  craata  another  generic  operator 


Quary  Window  Wad.  May  20,  1902  6  36  PM 


^OFQLCanuas/handle  click  l:Sdoinainclick  3:4 


canvas  point  av  rac 

^gdbobillsg 
H  • "  'a  ■  ■ 


^/shoiiv  hal[^{«  Tail  Objact  [■»^ 


^DFQLCanuas/tiandle  click  l:Sdomainclick  4:4 


^OFQLCanuas/handle  click  2:5terfnclick?  1:1 


pi 

«D^OLCanvas» 


(Instnvm  its  ntn  ler-nirai  »1 

^  I  ^ 


^  d  1 1  a c  h  •  1^' 
0  0 


NULL  0 


fail  case  uniass  chck 
was  on  a  larnitnai 
(input  nooe). 


Query  VV  naow  Weo.  May  20.  1W2  6  36  ?V 


Start  with  diawLinOr  oti  Turn  >t  on  Ramova  any  path  trom  tarminal. 
Daiala  any  lina  trom  tarm.  Imtiaiiza  to  hook  up  a  naw  ima. 


^OFQLCanuas/handle  click  2;Sdotermclick  2:2 


^DFQLCanuas/handle  click  3:5rootclick?  1:1 


Oue-y  W-r3ow  Wed  May  20.  1992  6  3€  PM 


^OFQLCanuas/handie  click  3:5dorootclick  1:3 


Qutry  Window  W«d.  May  20.  1992  6  36  PM 


^OFQLCanuas/handle  click  3:5dorootclick  3:3 


ezzzzszizzszszszszzzzzzsi. 


OOFQLCanuas/handle  click  4:Sinputbarclick  1:1 


Query  Window  Wed.  May  20.  1992  6  36  °M 


@OFQLCanuas/handle  click  1:Sdomainclick  l:4moue  to  new  location  1:l$et  new  location  l:tgetoffset  1:1 


^OFQLCanuas/handie  click  1  iSdomainclick  l:4moue  to  new  location  l:l$et  new  location  l:1set  new  location  1:1 


^20FQLCanvai/handle  click  I'Sfloramci.ck  t;4r  jve  !o  new  location  i:ise:  new  location  i  tset  new  ocatcn  i.ise;  'oottect  1  1 


^OFQLCanuas/handle  click  1 :5damainclick  l:4redrawobj  1;lfind  gdbobjn  within  region  1:2 


Query  Window  Wed,  May  2C.  tS92  6  36  PM 


^OFQLCanuas/handie  click  I .'Sdomainciick  l:4redraiiiobj  1:1  find  gdbobjs  uiithin  region  2:2 


^DFQLCanuas/handle  click  l:5domainclick  1 :4redraiuobj  1:1  redraw  1:1 


^OFQLCanuas/handle  click  2:5termclick?  l:1doonlyopc  1:2 


^DFQLCanuas/handle  click  2:5termclick?  1:1doonlyops  2:2 


OOFQLCanuas/handfe  cfick  2:S(fotermc(ic(c  CZiuati  until  mouset/p  1:1 


^DFQLCanuas/handle  click  2:5dotermclick  l:2if  not  click  on  root  then  draujLineOn  •  FALSE  1:2 


^DFQLCanuas/handle  click  2:Sdotermclick  1:2if  not  click  on  root  then  draiuLineOn  >  FALSE  2:2 


FALSE 

_ XT 

%driwLin*Or@ 
> - - a 


^OFQLCanuas/handle  click  2:5dotermclick  2:2update  terminallist  1:1 


Qu87  Winoow  Wm,  May  20,  1992  6  37  PM 


^DFQLCanuas/handle  click  2:5dotermclick  2:2add  to  rootlist  1:1 


^DFQLCanuas/handle  click  2:5dotermclick  l:2update  terminallist  I:1set  terminallist  1:1 


Query  Win3ow  Weo.  May  20.  1992  6  37  PM 


^OFQLCanuas/handle  click  2:5dQtermclick  l:2remoueline  1:1  update  rootlist  l.’irmufmrootnst  1:1 


Query  Wir.oow  Wed.  Way  20.  1992  6  37  PM 


^DFQLCanuas/handle  click  2:Sdotermclick  2:2update  terminallist  1 :1  remoueline  1:1 


^DFOLCanuas/handle  click  2:Sdotermclick  2:2update  terminallist  1:1  remoueline  1:lrmufmrootlist  1:1 


Query  Window  Wed.  May  20.  1992  6  37  PM 


^OFQLCanuas/handle  click  2:Sdotermclick  2:2update  terminallist  1;l  update  terminallist  I  :t  update  it  1:1 


Qo«rv  W.r.ao*  WbC,  Way  2C,  -39!  6  37  PW 


^OFQLCanuas/handle  click  3:5dorootclick  l:3makeinfo  2:3 


/  ^dbop./c^h.ekgripax] 


^eo~py^ 

XL 


^;dbop>/r««>^ 


^«dbob|/iii«k««litjB 

W 

adbobi 


Snouionl  raally  hmo  a  copy  hara 
tinea  wa  ramata  ina  litl  aoa'y  axacuiion; 
howavar  Iba  kaapt  adbobtliti  Iroin  EVER 
being  corrupted  (oinarwise  >t  would  be 
corrupt  attar  one  aiacution  and  betora  me 
next). 


^adjiobjl  itfi 


^OFQLCanuas/handle  click  3:Sdorootclick  1 :3makeinfo  3:3 


313$4 


Estot^aier^ 


Alert  should  say  that  tarminalt 
and  roots  are  not  connected 
correctly  User  should  check 
ha  query  graph. 


^DFQLCanuas/handle  click  3:Sdorootclick  1:3dispinro  1:3 


OuAry  Window  W«tf.  May  20.  1992  6  37  PM 


^OFQLCanuas/handle  click  3:S(lorootclick  l:3dispinfo  1:3 


XUMN  NAMES: 


^OFQLCanuas/handle  click  3:Sdorootclick  l:3di$pinro  2:3 


ODFQLCanuas/handle  click  3:5dorootctick  1:3dispinfo  3:3 


FALSE 


7 


(13) 

_  guprStrln^ 

^trom^asci^  7 


^thow^ 


{1.  *  a  not  In  th«  tat)l«  list* 
§2.  'Error  on  table  lookup!  * 


^DFQLCanuas/handle  click  3:5dorootclick  2:3utati  until  mouseUp  1:1 


Esuttor^ 


TRUE  (5 


Query  Wmaow  vVea.  May  20,  1992  6:37  PM 


^DFQLCanuas/handle  click  3:Sdorootclick  2:3$et  lines  1:1 


Query  W  ndow  Wed.  May  20.  1992  6  37  PM 


g^DFQLCanuas/handle  click  3:Sdorootclick  3:5update  terminaltist  &  rootlist  1:1 


point  *  .  .inoox 

I  insinum  gaBODjlist  i 


;tind-lnitinc< 


; update  lerminaliisi  of  start  oi 


^DFQLCanuas/handle  click  3:5dorootclick  3:3doline  1:1 


OOFQLCanuas/handle  click  3:Sdorootclick  1:3nriakeinfo  2:3setselect  1:1 


^OFQLCanuas/handle  click  3:Sdorootclick  l:3dispinfo  liSformatit  1:1 


^OFQLCanuas/handle  click  3:5daraotclick  1:3dispinfo  1:3formatit  1:lrepspaces  1:2 


Quary  Window  Wad.  May  20.  1992  6  37  PM 


{^OFQLCanuas/handle  click  3:5ilorootciick  2:3ir  not  click  on  terminal  then  draiuLineOn  >  FRLSE  l:2click  on  terminal?  1:1 


null  0 


g  \  ^AIL  case  jnlsss  click 

I  was  on  a  terminal 
\  (input  nooe). 


K^jflFQl  Cartvaayhanrtla  click  3:Saorootclick  2:3il  not  click  on  terminal  men  OrawLineOn  e  FALSE  t:2click  on  terminal'’  titdoontyops  1:2 


^^OEOLCanvas/handle  click  3'5<!orootclick  2:3i1  not  click  on  term.ina  "'er.  arawLmeOn  s  FA;.SE  i  2ci  ck  on  terminal'’  1:'aooniyoos  2:2 


^^DFOLCanvas/handla  click  3:5<)orootclicK  2:3it  nol  click  on  terminal  men  orawLineOn  =  FAlSE  1  2cIick  on  terminal'’  t  tdooniyops  1 :2cnecklerms  2:2 


Query  Window  Wed.  May  2C.  1 992  6  36  PM 


^OFQLCanuas/handlB  click  3:5dorootclick  3:3update  terminallist  &  rootlist  1:1  update  rootlist  of  destination  op  1:1 


^^OFQLCanvas/handlg  click  3:5aoroolci'CK  3;3up3ate  terminaiNs:  &  lootlist  i  iupaale  termer, aiiist  pi  start  op  trllmoterm  1:1 


Query  W.npow  Wea,  May  20.  1392  6  38  PM 


^OFQLCanuas/handle  click  5:Slocate  inputboH  1:1  locate  it  1:1 


^DFQLCanuas/handle  click  5:5locate  inputbox  1:1drauj  input  box  1:1 


^OFQLCanuas/handle  click  5:Slocate  inputbox  l:1draLU  input  box  l:1getRect  1:1 


^DFQLCanuas/handle  click  S:5locate  inputbox  1:1draui  input  box  1;1do  dram  1:1 


Fram»RoundR«c 


rnwurmmii 


Qu«ry  Window  Wod.  May  20.  1992  6  38  PM 


^Query  Object/calcrects  1:1 


StrIngWIdlh 


I  Batad  on  the  langtn  ot  tha 
Gal  rootracl  jf/  oparator  nama  dalarminas 
'  /  tha  coords  ot  tha  main  fact 

I  and  root  fact  (output  noda). 


^Query  Object/caicrects  1:1  Get  mainrect  1:1 


^Query  Object/calcrects  1:tCet  rootrect  1:1 


(U  0) 


^Query  Object/mktrmlst  1:1 


I  Givan  ttia  arlty  and  tha  langth 
I  of  tha  oparalor't  tx>dy  ractangla 
datarminas  whare  to  draw  tha 
larmlnali  (input  nodas). 


^makatharscts: 


Query  Window  Tue.  May  19.  1992  9  36  PM 


^Query  Object/mktrmlst  f  :1maketherects  1:1 


Qu^ry  Window  Tut.  May  10.  1902  9  06  PM 


^TeKt  Object/ setterms  1:1 


^TeMt  Object/create  1:1 


^Tent  Object/create  l:lget-display-strng  2:2 


^Operator/setterms  1:1 


OOperator/setterms  Irlmoueterm  1:1 


^Operator/set-attributes  1:1 


Quory  Window  TuO.  May  19.  1992  6  34  PM 


^Operator/create  1:1 


OOperator/create  1:1  get  instance  1:2 


^Operator/create  1:1  get  instance  2:2 


UseOp'  le>t 

HULL 


Qu«ry  Window  Tu*.  May  19.  1992  8  34  PM 


^UserOpr/actiueuieu)  1:1 


OUserOpr/actiueuieui  l:lupdate  menu  1:1 


^UserOpr/actiueuieuj  t:tupdate  menu  1:1  update  Fite  1:1 


^UserOpr/uiewop  1:1 


U$«s  ssisct  dialog  to  display 
avaiiabia  user  oparalo's. 

Takas  tn«  on«  tnat  was  saisctad 
and  displays  it  in  ine  Viaw 
Usar  Opaiatof  -  window 
Concatar.alas  ina  nama  ol  ina 
usai  opaialof  baing  ditplayad 
to  me  window  name  so  it  gats 
displayed  in  tne  litie  bar. 


Goery  Window  Wed.  Way  20.  tag?  5  57  PM 


^UserOpr/uieuiop  l:lupdate  menu  1:1 


^UserOpr/uieuiop  1:lget  UsrOpr  luindou;  1:1 


|l.  UMr-0«(in«d  Oparator 


Query  W.naow  Wed,  May  20,  1992  5  57  PM 


^UserOpr/uieiuop  lilupdate  menu  IMupdate  File  1:1 


^UserOpr/uieiiiop  1:1  get  UsrOpr  uuindouf  l:lpreuious  win  loc  2:2 


Quary  Window  Wad.  May  20.  1S92  5:57  PM 


^UserQpr/ delete  input  1:1 


^UserOpr/cancel  1:1 


^UserOpr/delop  1:1update  operators  list  in  Help  window  lilupdate  HelpList  1:1 


OUserOpr/delop  1:1update  operators  list  in  Help  uiindoiu  I  :l  update  operators  list  1:1 


^UserOpr/delop  1 :1  update  UsrOpr  pop-up  menu  1:1  find  all  Query  lUindoLU  1:1 


Query  Window  Wed.  May  20,  1992  5.57  PM 


OUterOpr/ delop  I :l update  UsrOpr  pop-up  menu  1  :l  find  ail  Query  UJindom  I  :l  find  QueryUJindouis  1 :2 


^UserOpr/deiop  lilupdate  UsrOpr  pop-up  menu  Itlfind  all  Query  lUindom  Irlfind  QueryUJindouis  2:2 


«Manu» 

l^get  window  a  canvas^ 


Sets  up  Query  Window  screen 
^  to  accept  aelinition  ol  a  new 

I  locate  "nSarRect  5 1  us»'  aelmed  operator. 

'  u  Setupiiems  turns  oft  all 

buttons  ana  menu  selections 
NOT  associated  wiin  use’  op 
delmit.on. 


^/drawiripulba^ 


update  menui^'l 


Query  Window  Wed,  May  20.  1992  5  57  PM 


OUserOpr/neujusrop  1:tset  some  attriuutes  1:1 


Query  Wmaow  Wed.  May  20,  1992  5  57  PM 


^SUserOpr/neuiusrop  lillocate  inBarRect  1:1 


^UserOpr/neuiusrop  I :t get  ufindou*  &  canvas  1:1  set  attributes  1:1 


^UserOpr/neuiusrop  1:lget  uiindoui  &  canvas  lilset  attributes  1:lget  ivindow  location  1:2 


~a 

NULL0 


na  1») 


^UserOpr/neuuusrop  1 :1  get  uiindoiu  &  canuas  1 :1  set  attributes  1 :1  get  uiindotv  location  2:2 


Firsi  checks  the  user  op  lor  correct 
connections.  Then  gets  the  name 
tor  the  operator  (getopname)  anp  the 
help  message  lor  It  (geinelplexi)  from 
the  user.  Then  ados  it  in  correct 
aiphabeiicaJ  order  (Oelermined  by 
geicpname  -  when  it  also  checks  lor 
attempted  use  ol  already  used  names) 
to  the  persistent  list  ol  all  user  delined 
operators. 


Query  Window  Wed.  May  20.  1992  S:Se  PM 


^UserOpr/storeop  2:2 


Mart  should  say  that  terminals 
and  roots  are  not  connected 
correctly.  User  should  check 
hk  query  graph. 


^UserOpr/storeop  1:2getopname  1:2 


^UserOpr/storeop  1:2getopname  2:2 


Query  Window  Wed.  May  20.  t992  5  S8  PM 


^UserOpr/storeop  l:2create  new  suropr  I:I 


^UserOpr/storeop  l:2gethelpteMt  1:1 


$1.  PI«aM  anlaf  help  information  tor  your  naw  opsrator. 
(Usa  option-raturn  to  dart  naw  linaa.) 


Quary  W  naow  Wao,  May  20,  i»92  5  58  PM 


^UserOpr/storeop  l:2defin  more?  1:2 


^UserOpr/storeop  l:2defin  more?  2:2 


Optrator  nam« 


<<QuaryWinaow>> 


^'/'cioV*^ 


nama  in 


Quary  Window  Wad.  May  20.  1992  5  S8  PM 


{1.  P(««M  •nMr  a  diffaranl  nama. 
S2.  '  It  alraady  In  utal 


Quary  Window  Waa.  May  20.  1992  S  Sa  PM 


^UserOpr/storeop  l:2create  neiu  suropr  IMgetcons  1:1 


^UserOpr/storeop  1:2update  UsrOpr  pop-up  menu  1:1  find  all  Query  lilindout  1:1 


Qu«ry  W»noo»¥  W«d.  May  20.  1992  5  56  PM 


^UserOpr/storeop  l:2update  UsrOpr  pop-up  menu  1:1  rind  all  Query  Ulindoui  1:1  find  Querylllindouis  2:2 


Qu»fy  W.naow  AM.  May  20.  ■.9&2  5  58  PM 


OHelp/shou;  help  l:IOpenHelptUindow  IrlSet  select  list  1:1 


^Help/help  click  1:1 


@Help/help  click  1:1handle  click  1:3 


Query  W.noow  WeO.  May  20.  1992  S.26  PM 


^Help/help  click  l:ltiandle  click  2:3 


$1.  (••(•ct  join  diff  union  projoct  groupcnt  eqloin  groupAllsatisfy  groupNsatisty  groupavg  groupmax  groupmin  iniarsact  DISPLAY  SOiSPLAY) 


@Help/help  click  l:lhandle  click  3:3 


§2 


$1.  *  can  not  bo  changodl 
$2.  Tho  doocription  ol  * 


^Help/tielp  click  1:lhandle  click  1:3CetTeKt  1:1 


Quory  Window  Wod.  May  20.  1992  5:26  PM 


^Help/help  click  IMhandle  click  1 :3CetUlindoui  1:1 


^Help/help  click  l:lhandle  click  l:3SetText  1:1 


^Help/help  click  1:lhandie  click  2:3ChangeHelpMessage  1:1 


^Help/help  click  1:1  handle  click  2:3Cettl)indouj  1:1 


^Help/help  click  1:thandle  click  2:3ShoujTeHt  1:1 
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